Re: LYNX-DEV long-term migration

[Klaus Weide]

On Tue, 8 Apr 1997, Al Gilman wrote:
> Klaus Weide asked:
> 
>   Now if you [anybody] have an idea how to make Lynx more
>   Netscape(et.al.) compatible (a.k.a. Un-HTML compatible) in a new,
>   structured way that doesn't bear those costs, and without sacrificing
>   correct treatment of valid markup, let's see it.
> 
> I interpret this question to be rhetorical.  

Yes and no.  I mean, I would *really* like to see the code for that.

> The discussion on
> this point in the past has usually conceded that if one were to
> make a clean break with the current code and design a replacement
> browser in a more modern programming paradigm, it would be easier
> to combine tolerance and maintainability.

Your writing paradigm sometimes has a tendency of reduced
understandability, at least for this reader...  There are some buzzwords
there which I don't quite understand when I come to think of what they
would mean.

> I have not laid out such an approach, because it leaves the
> next-generation team wandering a long time before they get to
> find out if they are hitting paydirt or just another dry hole.
> 
> What follows is my rough idea of how to maneuver Lynx into a
> more maintainable state by a sequence of finite changes that
> leave you with a working browser that keeps up its user base.
>
> To attack the long-term problem, we need to find some way to
> introduce modularity so that finite upgrades can eventually 
> renew the whole program.  
> 
> As I hear it, the big challenge is the parser.  Or to put it
> another way, a systematic rewrite of just the parser could
> provide more tolerance with high program structure clarity and
> maintainability.

Is this just a guess, a diffuse prediction, or can it be backed up by
logic or experience?
I remind you that "more tolerance" means guessing structure where the
author has failed to provide any.  (Or does it not?)
 
> The gotcha is that the "Lynx API" does not isolate the parser
> cleanly.  

Is that an established fact?
The parser, in the strictest sense, is just what is implemented
in SGML.c (together with the associated HTMLDTD.{c,h}).
It is reasonably well separated from other parts of the code.
(Well there are exceptions.)

> This is a chicken-and-egg problem.  To break out the
> parser, one pretty much needs to re-engineer the whole program
> for modularity [REPEAT from top].
> 
> So what does one do?
> 
> A training program.
> 
> My resident [i.e. amenable to friendly amendments] run-up plan
> for what to do before we tackle the parser is:
> 
>       first, the external Mail User Agent interface.
> 
>       second, the forms-mode replacement for the o)ptions screen.
> 
> These are two incremental projects each of which will give the
> end-user more capability and the maintainer less code to
> maintain.

And they have nothing to do with the HTML parser.
At least I don't see how.

> If we succeed in those two projects, we will have some people
> trained on how Lynx presently goes together, and we can think
> about tackling the parser reengineering.

I don't see how having those things done will train people to
tackle the parser.  If you want to push for those things, because
you think they are important, fine.  But don't try to pass this
off as a way to make Lynx understand NHTML (Non-HTML) in addition
to HTML.  Or explain what one has to do with the other.

[rest snipped]

> That's my $.02 worth; what do others think?

There. You asked for it...

   Klaus

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