Re: LYNX-DEV fotemods chartrans & SSL

[Klaus Weide]

On Wed, 22 Oct 1997, Foteos Macrides wrote:

> 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.

Please give a concrete example.

[ BIG SNIP ]
>       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-->

For those who want to try it, make that 
  <!--#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.  

Yes, that change was made in 2.7.1ac-0.61.  The "example interface"
broke when I added the -source -preparsed stuff (lynx -preparsed
crashed on www.microsoft.com which has comments that start with
"<!--#"). Therefore I had to change something.  I made the
modification that seemed most obvious.

> 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.

I also took that in part as a comment an my change.

I changed the function back to the previous interface, with an added
check.  I included most of your comments and added my own, since your
comments didn't address why I had to add the test.  Whether that is
ranting or not, everybody may decide by reading them in
src/LYCharUtils.c from -84ff., before "PUBLIC BOOLEAN LYCheckForCSI".

(There _was_ a serious error in 2.7.1ac-0.83, where I had already
changed back the interface in SGML.c but had forgotten to make the
equivalent change in LYCharUtils.c.  And yes I should have tested that
but didn't.  It was corected in 2.7.1ac-0.84.  That doesn't seem to
be what you are talking about though.)

> 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 :).

How come then that it _does_ work in 2.7.1ac-0.84?

I honestly think that you are completely wrong, and that you have not
checked your statements.  It seems I haven't found a way to disagree
with you that you wouldn't take personally.

> 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.

The rant is in the eye of the beholder.

>       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.

It is you who is expressing things in these terms.  

> 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.

Good for you.

>       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. 

You may also want to consider that there may be other reasons than stuff
to "get over", for not including all fotemods changes.  For example time
and complexity.

> 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)
> =========================================================================

I didn't know you were a collector...

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;