LYNX-DEV long-term migration

[Al Gilman]

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

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.

The gotcha is that the "Lynx API" does not isolate the parser
cleanly.  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.

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.

If we can crack that one, I think we are on our way to a product
that can be maintained and improved for a long time.  The present
ball of twine is, as many have noted, suffering from strain
hardening and getting more intractable the more it gets patched.

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

--
Al Gilman

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