Re: LYNX-DEV fotemods chartrans & SSL

[Foteos Macrides]

Nelson Henry Eric <address@hidden> wrote:
>>      Note also that I don't plan to use the devel code, or whatever
>> version that becomes, seriously myself, and thus will not be generating
>
>Not my place to ask, but even after reading your reasons for this
>decision, I still wonder why.  For selfish reasons (I only have time
>these days to test one code set), I wish you would reconsider.

        This was explained at length in the fruitless "discussions"
before Klaus' extended disappearance, and again more recently.  I'm not
optimistic that I can get it across any better than I've tried before,
but I'll give it another shot.  I use Lynx seriously in conjunction
with secure transactions.  In that case, it's caching and resubmission
logic are very important.  The INTERNAL_LINK stuff breaks that logic.
It may not resubmit form content when it should, which is not so bad
because you can force resubmission in such cases, and you usually
don't want to resubmit in most form-based secure transactions.  The
problem is that it also will force resubmissions when it shouldn't,
which is very bad in such cases, and precludes my using that code
seriously.


>I put all my eggs in one basket (the devel code) in the first place
>because you yourself said you no longer wanted to be the sole developer.
>So the lynx-dev community worked out a "team developer" system.  I
>believe it has been a VERY productive venture.  They are close now to
>putting out a release.  I know there is some dissatisfaction with the
>amount of time it has taken, but really it is a GIANT step, more like
>three releases of those in the past (so not such a bad track record
>for a first time effort).
>
>                       -*- release 1
>Lynx_w32 may be the future of Lynx.  With Microsoft's recent troubles
>with the anti-trust boys, they may have to bundle Lynx in with Windows95.
>If that were to happen, Lynx would be a SERIOUS competitor with MSIE.
>It's my prediction that Un*x/VMS questions will slowly wane, and there
>will be a flood of new questions about Lynx_w32 as it catches on.  People
>still don't know about it is all.

        I think that if you check the archives, you will find strong
encouragement on my part to make the DOS/WIN/NT ports an integral
part of the devel code for the next release.


>                       -*- release 2
>Autoconf doesn't mean much to you, but it means a LOT to us quasi-sysadmins
>who can barely keep their head above water as is.  It's a real boon in terms
>of saved time and trouble for us running wide-access Lynxes on Un*x machines.
>It's also quite useful to the handful of people who rely on login accounts
>for access to the Web.  Another side-effort of one developer extended color
>support to almost all curses, not just slang (and the problematic style sheet
>code).

        I think that if you check the archives, you will find strong
encouragement on my part to add autoconf for the next release.  Some
time before that, when the libwww was still alive, there were still
hopes of adapting a more current version of it for Lynx, and it was
not based on an autoconf, but on platform/flavor specific ifdefing,
John Davis wrote an autoconf for Lynx, and I was reluctant to include
it, because it would be at odds with the then still alive libwww
development.  But once the libwww switched to an autoconf, so did
my opinion about that.  I also think that your impression reflected
in "doesn't mean much to you" is at odds with the way I in fact
persued Lynx development thoughout the years when I acted as its
coordinator.
 

>                       -*- release 3
>"chartrans".  Without it, Lynx would already have it's second foot in the
>grave.

        I certainly agree with that, and that's why I put so much effort
into making sure it wasn't lost when Klaus went into his extended
disappearance, until we had to assume he had gone for good.


>Lynx (devel code) has a lot going for it.  If the "godfather" seems to be
>turning his back on it, that's going to discourage the new talent out there.
>
>Something I thought I'd never be translating, but since it's been on
>netnews for anyone to read, perhaps I should.  You know, Fote, you're
>not overly popular here among many of the programmers who know of you.
>They refer to you as "hone - kay" [ $BK\2H(J ].  That's a complement on the
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>surface, since it means you are the defacto head of the household.  But
>from the point of view of a promising young upstart banging at the front
>door it has a totally different nuance, perhaps hard to grasp unless
>you've been raised in a society with very deep feudalistic roots.  So
>what does the devel code become, "boon - kay" [ $BJ,2H(J ]?  (May sound,
>i.e., be pronounced, like `boon', but it will more likely spell the end.)
>
>More than what it has become, the *way* Lynx (devel code) was produced
>is an amazing achievement.  Somehow, someway, I wish you could find a way
>to participate and support that effort.  Even if you can't join the team
>there has to be a way.
>
>I've been frank.  Let it be known that that's because I respect you highly,
>not the other way around.

        As usual, and no offense or disrespect intended either, you're
way out in left field, but raising the relevant issue, albeit naively.

        Let me share with you the latest manifestation of the relevant
issue (though you may not grasp it all :).  Quite some time ago, the
OBJECT element was new and seemed likely to be adopted by the Big Two
as markup even better than FIG for inlining - not restricted to images,
and still offering substantive fallback options for non-GUIs such as
Lynx.  At the same time, there were extensive discussions in lynx-dev
about handling TABLEs in Lynx via external scripts which convert them
to PRE formating and feed the result back for rendering and display
(with a number of people working on such scripts, and offering alpha
or beta versions for testing via http CGI procedures).  In addition,
at that time, there were some Lynxers clamoring for a means to do CSI
(client-side inclusions) based on "comments", homologous to the then
popular SSIs (server-side inclusions based on "comments"), so that
when you access the files via http, the server does the inclusions,
and when you access them locally via file://localhost/path URLs,
Lynx does the inclusions.

        So I set up buffers for back and forth interactions between
the structured objects for parsing and displaying hypertext (and in Lynx,
both text/html and text/plain are handled as hypertext, albeit meagre
and "artificial" for text/plain -- Lynx is not a "file viewer" :). The
OBJECT markup uses a "include" buffer, as would the TABLE markup if
it had really gone anywhere.  There is also a "csi" buffer for the
CSI, though that's still just at a "feasibility" demonstration stage,
waiting for people to follow through, which they didn't, on writing
a ./src/LYCSI.c basically copying the SSI code from any http server.
If you had "vanilla release" code, or the fotemods code, or devel
code *before -84*, the "feasibility" demonstration could be done as
follows.  Add:

<!--LynxCSI-->

to any text/html file, and when you accessed it via a
file://localhost/path URL, you'd get an inclusion of:

URL: file://localhost/path

Diddley squat, but it shows that if a ./src/LYCGI.c which processed
comments homologously to SSI by an HTTP server (instead of the dummy
LynxCSI with no directives following it) were added, then you'd have
the server, not Lynx, doing the inclusions when the file was accessed
via an http URL, and when accessed as a local file, Lynx could do
them.

        The latter depends on checking the URL (the node_anchor address
for the appropriate structured object) which was used to access the file
for whether or not it is "file://localhost/*" (with local host domain
substitutions if it is not literally "localhost").  At the time I set
that up, the SGML parser's structured object did not keep a copy of
the anchor, and so I added an LYCheckForCSI() in the Lynx_HTML_parser
family for checking the node_anchor address in the HTML parser's
structured object's node_anchor address and loading it into a "url"
buffer for the SGML parser.  As part of the chartrans mods the SGML
parser now keeps its own copy of the anchor, so there's no need for the
LYCheckForCSI() - the SGML parser could check the node_anchor address
itself.  In the devel code, the function was changed to pass the SGML
parser's copy of the node_anchor's address, instead of its current
"target" for identifying to the HTML parser which structured object
should be checked.  That's pointless at this point, too, since the
SGML parser could just check it's own copy, but it still worked, to
do the "feasibility" demonstration as intended.  In the course of winding
up the fotemods, I recently added a lot of comments to explain what
the code is doing (as I always do when winding things up, at this point,
I suppose, as my own compulsive behavior for code ideally to be
understood, with due but not unreasonable effort, by anyone who has the
programming skills and puts the time into understanding and further
developing it).  That included an explanation of why I had left
LYCheckForCSI() as originally, and what was it's original intent.
Shortly thereafter, in devel revision -84, Klaus copied my comments
about LYCheckForCSI(), interdigitated with his own, as nonsensical
as the things he wrote to the list (in self-righteous, bull-headed
rant mode :) about the INTERNAL_LINK stuff before his extended
disappearance.  He also added a check for whether the call had come
with a "Lynx_HTML_parser" isa signature, which is nonsense, because
the call comes from the SGML parser, which has an "SGMLParser" isa
signature, and has the consequence of breaking the demonstration
(if you try it with devel -84, it doesn't work any more :).  Moreover,
adding that isa signature check makes no more sense than adding such
checks for the SGML parser's calls to HTML_start_element() and
HTML_end_element().  That would break Lynx entirely, and would be
noticed immediately, so don't worry about Klaus doing that. :)  My
point though, is that he took fully working code, somewhat different in
the devel versus fotemods, but fully working in both, and broke it,
didn't even check whether it still works, simply to copy in my
explanatory comments and interdigitate his own.  I realize you are
not a programmer, and this may seem very complicated to you, but I
assure you someone as highly intelligent and skilled as Klaus would
not write and do anything that stupid unless something in my comments
had set him off again into self-righteous, bull-headed rant mode.

        When a dog runs around the yard peeing on fence posts, the
result may be pleasing to itself, but to the others those scent marks
are territorial warnings -- not necessarily consciously, but that's how
they function -- homologously to other kinds of posturing in human
"feudalistic" systems.

        Almost none of us participating in Lynx development actually
"know" each other, beyond what we infer about each other from messages
exchanged on this list.  I happen to be a hippy from the 60's.  And
those are the kinds of people with whom I enjoy spending my "spare
time" interacting, no matter what their ages (I'm too old and grey
to be called a "flower child" myself :).  There have been a number
of such people involved in Lynx development (and there still are
some, though perhaps too young to recognize that jargon, or how it
applies to the current decade :) and I have very much enjoyed myself
interacting with them.  I also have a "college graduate" daughter and
we very much enjoy "intellectal sparing" with each other, but earnestly
care about each other, and don't really care who "wins" this round.
I have no interest in being a "professional" in my "spare time",
certainly not what that term has come to mean in the '90's, nor in
being a "hone-kay" or "godfather" -- being treated deferentially while
in fact seeking dominance.  Sorry, that's just not for me.

        Don't worry about it, Henry.  Almost everything I've done
since the last Lynx release has been included in the devel code set.
I'm going to wind up the fotemods as still lynx2-7-1f, an older
version than whatever will be used for the next "release", and
perhaps Klaus will get over whatever set him off this time, and
include more stuff from that.   So don't worry about it, OK?

                                Fote

=========================================================================
    "Tom, please don't just copy Fote's for-slang code without checking.
     We can create our own bugs just fine."
     -- Klaus Weide,
        coordinator of Lynx development (hone-kay == $BK\2H(J)

    "SLANG - it's best classified as experimental."
    -- Thomas E. Dickey,
       ncurses maintainer, Lynx authoconf maintainer,
       and Lynx hone-kay's lackey.

    ":) :) :) :) :) :) :) :) :) :) :) :)"
    -- Fote,
       Lynx has been (displaced hone-key)
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;