Re: lynx-dev Javascript

[Bela Lubkin]

Lalo Martins wrote:

> Who is responsible for integrating patches? I'd like to hear
> from this person, is there interest in integrating the libjs
> stuff, as experimental as it is?

Our Great Integrator for the last, what, two years?-- has been Tom
Dickey.  I'm sure he'll speak for himself, but I'm also quite sure he
would not object to integrating some useful JavaScript functionality.

Lynx development is pretty democratic, anyway.  The general rule is,
stuff gets developed if there is enough demand for it (including one
person generating his own demand and therefore developing his own code),
and it gets integrated if it isn't actively destructive.

As to JS itself, yes, there has been *tremendous* demand for it over the
years.  Also for Java, of course, but that's a separate issue.  If Lynx
could handle all JS pages, that would open a large portion of currently
inaccessible web territory to Lynx users.  Yes, I know that JS support
does not mean we will "handle all JS pages", but presumably we could
make an asymptotic approach.  Once the first steps are taken, who knows
how far we can go...

=============================================================================

As with any other major Lynx enhancement, this one will need to be
easily disabled.  That includes:

  - it should still be possible to build Lynx binaries without JS
    support (and this should be the _default_, at least at first);

  - administrators of public access sites will want to be able to
    prevent anonymous users from using it, which means integration with
    the "-anonymous" and "-restrictions" flags and probably a
    system-wide override in lynx.cfg;

  - individual users will want to be able to control it, probably with a
    variety of different levels, such as:

      o never run any JS at all
      o prompt for confirmation on each page that uses it
      o on a site-specific basis, never, always, or prompt whether to
        run JS
      o when prompting for confirmation, some users will want to be able
        to inspect the actual JS source, some will not.  (This might be
        another setting on the wheel from "never" to "always", allowing
        site-based control: "never", "prompt", "prompt w/source",
        "always".  And, I suppose, one of the answers to the "prompt w/o
        source" prompt might be "I changed my mind, show me the source."

    These controls might be modeled after (and share code with) the
    current cookie controls.

I'm not saying you Must Implement all of this stuff from the start; just
be aware that there will be demand for these things.  Try to model your
implementation with the expectation that it will be called on to provide
these features as soon as it's vaguely stable.

> I'm planning to keep up with the lynx development version. As
> soon as I can distribute the patches, I will be releasing them
> as often as possible (in practice: as soon as a given batch of
> change works, make it into a patch). But for the next few days I
> can't distribute anything, till there is a libjs released under
> GPL (nobody outside Mozilla knows how long; 2 weeks? One month?)

Sounds good.  Thank you for taking up this project!

>Bela<