[Info-vax] Using VMS for a web server

[Stephen Hoffman]

On 2015-06-05 20:49:40 +0000, David Froble said:

> 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.

OpenSSL is ported over.  CDSA is ported over.  cdrecord is ported over. 
  Apache is ported over.  php and Perl and Python are ported over.   
ICS and zic and related time-handling tools.  TCP/IP Services is ported 
over.   libxml2.  gSOAP.  SVN.  All sorts of stuff that folks are using 
and are increasingly depending on.

> Basically, I'm not too interested in porting Unix stuff to VMS.

You might not be.  But you're very likely dependent on ported code.  
More than a little of what folks are using can be.

> I'm sure there are people who are interested, but I'm not, and all I'm 
> saying is not everyone is.

I too wasn't all that interested, but then realized I was going to end 
up writing and supporting a whole huge pile of code to deal with a 
common format, or port over a common library that dealt with the format 
for me.

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

It's rare for customers to target OpenVMS for their solutions, and 
which is something VSI is undoubtedly aware.   Most customer 
application requirements and expectations are either OS independent, or 
they're not OpenVMS-specific.   The components of many of the 
applications and solutions are increasingly fungible, too.

> ...
>> 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.

Yes, for folks operating in US ASCII, implementing case insensitivity 
is easy and can be obvious, and can be easy to implement due both to 
ASCII and to the way that English works.

Unfortunately, in the wider world and in the Unicode world, this 
simplicity quickly becomes a whole 'nother mess and a quagmire.   Most 
folks are pretty quickly using a library — quite possibly a library 
ported over from Unix — and hoping that the authors got this right.

FWIW, there was a discussion of one of places where case-blindness can 
bite, with ß / eszett / scharfes S / sharp S, not that long ago, too:
<https://groups.google.com/d/msg/comp.os.vms/PeqVjG3Mtxc/NF0shBmiGakJ>

Case-sensitive names can be little more than byte comparisons.  Those 
are much simpler to implement.

As much as you or I might like case insensitivity, there are trade-offs.

-- 
Pure Personal Opinion | HoffmanLabs LLC