[Info-vax] Using VMS for a web server

[Bill Gunshannon]

In article <mkt1s9$i52$1 at dont-email.me>,
	David Froble <davef at tsoft-inc.com> writes:
> Stephen Hoffman wrote:
>> On 2015-06-04 05:21:52 +0000, Dirk Munk said:
>> 
>>> JF Mezei wrote:
>>>> If VSI continues to support "Apache" on VMS, then it should be *Apache*
>>>> , not some proprietary port.  A proprietary port means that when patches
>>>> or new features become available to the world, they are not availble to
>>>> VMS customers.
>>>>
>>>
>>> You will always have to adapt Apache in order to get it running on 
>>> VMS. Apache is a Unix application, and VMS is not Unix. So it will 
>>> always be a proprietary port, and any patch will also have to be 
>>> ported to VMS I'm afraid. Apache will have VMS specific extensions, 
>>> but I don't think it was ever the intention to make it more 
>>> proprietary than necessary.
>> 
>> The various Unix systems are different from OpenVMS, certainly.  But 
>> wouldn't easier ports of Unix applications over to OpenVMS be 
>> preferable?
> 
> While I read where lots of people mention this, I'm not sure I agree. 
> My feeling is, if it''s Unix you want, then get and use Unix.

It's not Unix or VMS taht anyone reasonable wants.  What they want are
applications to do their work.  As it turns out right now, there are a
lot of them on Unix and almost none on VMS.


> 
> Basically, I'm not too interested in porting Unix stuff to VMS.  I'm 
> sure there are people who are interested, but I'm not, and all I'm 
> saying is not everyone is.

Apparently no one is or they would be porting them.  :-)

> 
> VMS is better at solving VMS problems than at solving Unix problems ..

There are no VMS problems.  There are no Unix problems.  There are business
problems and that is what people want to be able to solve. Right now, it
appears most of the solutions are on Unix and there are no options available
for doing it on VMS.  Personally, I don't see that as VSI's problem as none
of these applications are a part of VMS.


> 
>>   You're not going to get much of a market with Windows 
>> applications and something akin to Cygwin, after all.   But FWIW, it's 
>> not that the *ports* are different — Apache ports are always different — 
>> it's how you manage and extend the platform that matters to the folks 
>> that are going to be configuring and operating and troubleshooting the 
>> port.   Once I know where the configuration files are, and tools such as 
>> apachectl, I can generally get an Apache server to do what I want.   I 
>> don't need to learn a whole new batch of configuration file syntax, and 
>> a new set of OpenVMS-integrated tools.  This if I even need to go to the 
>> command line, which is something that I'm needing to do less often, and 
>> not something I'd encourage going forward.
>> 
>>>
>>>> Also, "<company> Secure Web Server" has 0 marketing value. If VSI can
>>>> claim that Apache runs on VMS, then this has marketing value.
>>>>
>>> Yes, you could be right there.
>>>
>>>> Also having WASD for higher performance wich takes advantage of VMS
>>>> would be good for those who prefer a less common web server that fits
>>>> better in VMS.
>>>
>>> My reasoning to think of WASD as the primary web server is this:
>>> Some one who is used to Apache on Unix will most likely not be used to 
>>> using VMS.
>> 
>> True.  But they will know Apache syntax, once they are able to find the 
>> Apache configuration files.
>> 
>> As for changing web servers, some of my larger customers are using 
>> Apache on OpenVMS.   Are you planning to deprecate Apache, or to support 
>> both Apache and WASD?
> 
> Never has to be "either or".  But I have to ask, but, I have to ask, how 
> long has it been since Apache has been supported on VMS?  Or for that 
> matter, anything else on or part of VMS, but that is being adressed by 
> VSI for the future.  Perhaps they'll be interested in supporting web 
> server(s).

What happened to "the right tool for the job".  Just what is it about VMS
that makes it a better choice for running a webserver than one of the
existing Unix options?

> 
>>> Someone who is used to VMS will perhaps not be used to the Unix style 
>>> of doing things as with Apache.  So if WASD is doing things in the VMS 
>>> way, then VMS people will be able to setup a WASD server faster then 
>>> with Apache.
>> 
>> You're presuming that the folks involved either know or will want to 
>> learn how OpenVMS does this stuff.   Better integration of common tools 
>> is goodness, but assuming folks know OpenVMS means you're limited to the 
>> installed base.  TCP/IP Services faced this same mess — there are a 
>> variety of tools that are used to configure and troubleshoot and test, 
>> and there are those folks that wanted the OpenVMS syntax, and there are 
>> (a whole lot more) folks that wanted standard names and standard tools. 
>> When there are common practices and tools, being different is something 
>> you need to be extremely careful about.
>> 
>> 
> 
> Standard names, as in "case sensitive"?  No thanks.

Funny, you used mixed case in the sentence above.  The teletype is gone.
we actually have 52 lettters to choose from now just like every natural
language I am aware of.  Well, except maybe for ASL. :-)  Is VMS deaf
as well?

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>