[Info-vax] Web Browsers, Web Servers, Web APIs, Server-Not-Client (was: Re: Vax Station 4000 VLC)

[Stephen Hoffman]

On 2018-12-27 02:42:12 +0000, Dave Froble said:

> On 12/26/2018 9:11 PM, Bill Gunshannon wrote:
>> On 12/26/18 8:52 PM, Dave Froble wrote:
>>> On 12/26/2018 12:36 PM, Bill Gunshannon wrote:
>>> 
>>>> Define "vendor".  All of the current browsers, except one, are 
>>>> developed by third party sources.  Why should it be otherwise? No one 
>>>> here is asking VSI to develop a web browser.  Only to provide the OS 
>>>> necessary parts to run one.
>>> 
>>> And what does that mean?  Turn VMS into WEENDOZE and Linux?  Why bother?

I suspect y'all are discussing the differences and the merits among 
providing the APIs necessary for a browser port, providing that browser 
port, and providing a proprietary and vendor-specific browser.

Providing a browser on OpenVMS will make about three folks happy, and 
then we'll be chasing problems such as TLS patches.  Neither HPE nor 
VSI have typically tracked current open source versions and updates, 
and the updates that have arrived have not been expeditious.  This is 
an issue in general of course, and a problem for browsers and other 
frequently-updated and frequently-targeted open-source packages.   I 
just don't see VSI as being interested in investing in keeping a modern 
web browser current.

>>> If the browsers are developed to work in specific environments, then 
>>> how can an environment that is different be expected to support those 
>>> browsers?

Most of the web tooling is based on and assumes a modern C or C++ 
library, and related tooling.  OpenVMS has fallen behind here, and in 
various ways.

>>> If the tools used to develop a browser are specific to Linux or 
>>> WEENDOZE, then the development of the browser(s) itself precludes 
>>> environments where the tools don't exist, or perhaps cannot exist.

A browser here would better be an HTTPS client and HTTPS server API, 
useful for tasks including replacing the disaster that is the current 
OpenVMS patch process.  Poll an RSS periodically, and fetch the kits, 
and provide notifications and staging.   Optionally automatic installs, 
on an opt-in basis.  An API and tooling to monitor push notifications 
from VSI, if quicker notifications are required.  This is not a web 
browser, though.

And yes, OpenVMS does need a current web server embedded, though that's 
expected to be present—though not necessarily enabled—on most any 
modern server.

Generic browsers and generic GUI on OpenVMS or on any other similar 
server?  Less interesting.  Particularly if SMB client and SMB server 
capabilities and potentially WebDAV become available in base OpenVMS, 
which makes pushing around files directly available from most current 
desktops.  Or push the files around using sftp if not.  And preferably 
with the OpenVMS tools updated to be vastly more tolerant of having 
their files pushed around as is common practice now, and preferably 
without throwing a snit.  And if the patch tools are overhauled and 
dragged forward in preparation for the third decade of this millennium, 
rather than for the last decade of the previous.

>> Back in September of 1980 there was a paper written called "A Virtual 
>> Operating System". ...  Sadly, it was an academic endeavour and we all 
>> know what happens when academics get bored.  But the fact is it was 
>> done and could be done again.
> 
> POSIX ended up being "everybody look and act like Unix".

In 1994, the DII COE definition effort started.  DII COE was 
effectively targeting Solaris compatibility.  The DII COE compliance 
effort was less than successful in the market, at least as OpenVMS was 
involved.
https://static1.1.sqspcdn.com/static/f/702523/9457087/1290003581557/200110-Frazier.pdf 


Those requirements have seemingly ended up being solved a little 
differently, with most sites now running either Microsoft Windows 
Server or Linux, and with Windows now starting to adopt Linux APIs and 
capabilities with Microsoft Services for Linux (SfL).

Then there are various make tools and which are a subset of something 
akin to DII COE, and which seek to address some build-related issues.  
cmake is recently seeing some popularity, and VSI was planning on 
releasing a port of that eventually per some earlier discussions and 
presentations.  OpenVMS is weak here, and there've been various folks 
around the edges here including the folks involved in the Open Source 
discussions, as well as the usual mess that is kitting and 
distributions and patching.


-- 
Pure Personal Opinion | HoffmanLabs LLC