lynx-dev "shell" and other accounts (was: COOKIE_SAVE_FILE wrong)

[Klaus Weide]

On Tue, 21 Dec 1999, Henry Nelson wrote:
[Larry:]
> > They all have 'a shell account' as they all have either Unix workstations or
> 
> JFTR, I was talking about what is described in the second paragraph of
> the _Lynx Users Guide_ as:
> 
>    Lynx can be used to            ...                       build
>    information systems intended primarily for local access. For example,
>    Lynx has been used to build several Campus Wide Information Systems
>    (CWIS). In addition, Lynx can be used to build systems isolated within
>    a single LAN.
>
> As I understand, and as I have experienced one such system on a community
> net in California about 4 years ago, Lynx becomes a "pseudo-shell," and is
> essentially the only interface the user has to the system.

That is not what people usually mean with the term 'shell account'.

>  Is anyone *building* (entire) systems based
> on Lynx in this day and age?  No.  

I don't know.  Sure, we don't hear about such efforts on lynx-dev.
I have to wonder, though, what people mean with messages like
in <http://www.flora.org/lynx-dev/html/month1199/msg00251.html>,
snippets:
  "using Lynx as a browser in any type of critical environment"
  "My company is considering a large scale adoption of Lynx"

> Is anyone aggressively  maintaining and
> updating such systems?  I seriously doubt it. 

I think it's still a bit early to declare freenets completely dead.
Sure, lynx-dev doesn't hear much from them any more.

> Would any *suggestions* I
> might make concerning current development versions of Lynx affect such
> people?  No.

As long as it remains a suggestion, and nobody follows it, of course
not.  If somebody follows it - why, yes (depending on the contents
of the suggestions).

Lynx has some capabilities that are rarely used, and that nearly all
"typical" users these days don't care about and don't know about.
Does that mean we should forget about them, and pretend they aren't
there?  In my opinion, no.  I know that that is not what you are
suggesting, but I'm afraid that would be the practical end result of
following some of the "let's not care about those ancient application
areas any more" tendencies.

Some of those "old" mechanisms, etc., are deeply ingrained in what
Lynx is.  Taking them out would really require some significant
effort, systematic revisiting of many parts, otherwise we'd just have
a confusing mix of code that does care and code that doesn't care,
which is worse than the presence of rarely used code itself.

I should say here that I am not referring to any specific recent
suggesting; I am responding in a general way to your general remarks.
There is one concrete area I have in mind right now, though, and that
is Lynx's "-restrictions" architecture.  It is a nice system for
controlling whether different kinds of things are allowed or not, at a
detailed level.  But it isn't generally used, or understood (even
folks who do offer some sort of restricted access may just use the
generic "-anonymous", leaving the more detailed controls completely
unused).  When I looked at this area a while ago, I found that it had
fallen into disuse and disrepair.  (Restrictions were not being
ckecked at all for soem new functions - apparently nobody had thought
of it.  Some related flags were used in an ad hoc manner without
proper regard for details, so the most popular "-anonymous" still
worked, I think, but more detailed control didn't.)  I fixed this (I
hope successfully) in 2.8.3dev.1 - not because I need detailed
restriction control, but because I prefer to work with a program where
even the more arcane command line flags work consistently (and as
documented - as far as that goes), rather than only somewhat work.
I can see 4 possibilities in such a situation:
(1) Get rid of the old feature completely.
(2) "Streamline" the feature, keeping only parts that are used.
(3) Don't care, leave old stuff but don't use it in newer additions;
    let entropy take its toll.
(4) Continue to support the rarely-used feature, as best as time /
    someone's interest / understanding permits.

(1) is work to do cleanly.  It's harder to get a feature out of the
code than getting it in...  Someone needs to be sufficiently
interested.  And the presence of some unused code isn't really much of
an "itch to scratch", compared to some missing feature one may want.
Besides, who is prepared to stand behind announcing the next release
with words like "Note: starting with 2.8.xxx, Lynx does't support yyy
any more.  If you need yyy, we can only advise you use 2.8.(xxx-1),
but you won't get all the fixes and new features we did since then."

(2) is even more work.  In order to not screw it up, it requires
understanding in some detail how it was supposed to work, and then
redesigning it in a more logical way.  If someone comes this far,
he/she may see that it's a neat feature after all, and go to point (4)
instead.

(3) - I just dislike it.  I hope I am not the only one.

(4) - After all, why not.  Especially if keeping the rarely-used
feature around doesn't impose too much overhead, and supporting the
old feature doesn't contradict new developments.

Well I hope this still has *soemthing* to do with what you were
talking about...   Do you think so?

I guess my main points are, "discontinuing support" has costs, too,
especially when it is done The Right Way, and they may be higher than
continuing support; and there has to actually be someone to invest the
time.


   Klaus