Re: lynx-dev lynx and javascript ?

[Al Gilman]

to follow up on what Larry W. Virden said:

> as long as the API has nothing specific to SSL, then something
> could be worked out.  I don't see how that could be considered
> much different than the SSL proxy.

There is an argument from usability, specifically as regards what
the user has to cope with to get the capability installed.  Since
you don't really intend to use the proxy as anything but a pipe
(never go around it), putting the user through the agony of
dealing with socket numbers and all that for something that
should be a patch/upgrade from the user perspective can cut into
our realized user base.  Enough users just won't cope with a
proxy solution.  Not unless we have the installer problem worked.
It doesn't matter whether it is a DLL or proxy, so long as there
is a foolproof installer for however it works.

The proxy uses sockets.  On 32-bit Intel (the Win32 port) we
have no trouble using sockets as the interface to the SSL engine.

On DOS we have all kinds of trouble until Michael comes across
with a DOSSOCK solution.  I suppose that the linux-lite-over-DOS
stuff is another way to try to achieve DOS interface.  Of course
on DOS we don't have Windows DLL support.  <repeat this para.>

The question in my mind has to do with 16-bit Windows: 3.1 and
3.11.  There the DLL API is available and could be used to
isolate ECMASCRIPT or SSL support.  In particular, we could
possibly make a www-lib DLL which was 16-bit-clean much more
easily than we can make the whole of Lynx 16-bit-clean.

All of this is speculation.  I am just groping.  But the Win 3.1
gap is a thorn in the side of our any-platform claims.  Then
again, we can do as the commercial free guys do and support "Mac
support is coming some day, but we will never go back as far as
16-bit Windows."

Al