Re: LYNX-DEV Re: todo-list question

[Foteos Macrides]

Nelson Henry Eric <address@hidden> wrote:
>> evaluate -- however that'd be a new feature (we can keep on delaying a
>
>Definitely a new feature.  Not something for now.
>
>> Perhaps - but let's try to move forward : seeing a workable program
>> will get some interest from people who might want to improve it.
>> (A lot of people simply won't look at lynx unless we declare it to
>> be an "official release).
>
>For sure!  I'm very happy this has been said.  The "vibs" I get from
>Fote seem to say "okay", so yes, _let's move forward by all means_!

        Sorry, but those "vibs" seem to be your own wishful thinking
rather than a valid interpretation (adequate understanding) of what I
have posted about the development code.  The (1) change in caching logic
associated with the INTERNAL_LINK stuff (not undone by the compilation
symbol), the (2) change in structured object interactions associated with
the preparsed stuff (added as a debugging tool useful only to Klaus, if
anyone), and the (3) excessively complex and unmaintainable aspects of
its chartrans implementation, still preclude my using the development
code seriously or as a basis for further development of HTML 4.0 and
HTTP/1.1 support.

        I do not wish to keep repeating that sad message to this list,
but please, yourself, stop misrepresenting what I have said.

        The (1) chartrans implementation in v2.7.2 is still more complex
than I would like, but maintainable, and thus far has needed only
trivial tweaks in characters used for 7-bit approximations (something
that will always be subject to change based on the preferences of
those who actually speak the respective languages; when I get a
sufficient block of time, I'll also be revising the approximations
for Greek, as was recently done for Russian Cyrillic), and choices
of MIME names under circumstances when conventions for them are still
evolving and are not yet consistent across the major browsers and
mailers.  The v2.7.2 chartrans implementation does everything that's 
actually needed for document charset -> current Display Character Set
conversions.  It does not include the probabilistic stuff and
associated ACCEPT-CHARSET code for doing conversions on form
submission, but because that's still utterly alpha in the development
code, and done in a way that would be difficult to coordinate with
eventual implementation of file upload support and scripting support.

        The (2) INTERNAL_LINKS and (3) preparsed stuff are not in
v2.7.2 (and never will be in any code that I use seriously).

        There is also the problem that the development code's
autoconf has been done in a way that creates problems for VMS with
DECC (which long ago replaced VAXC as it's compiler, though support
for old VAXCs and for GNU C should be kept up, IMHO, if VMSers who
have access to them become more active contributors).  Those problems
are fixable, but even ones diagnosed long ago by TD have not been
fixed (e.g., the redefinitions of BOXVERT and BOXHORI in userdefs.h
and LYCurses.h ).

        There is also the issue of the "alternate" SortaSGML parser,
which is now the development code's default.  That initally was done
as an "experiment" (Klaus' own description) with this comment in
HTMLDTD.c, which still applies:

[...]
**      An important design goal was that info for each tag should fit on
**      one 80 character screen line :).  The price to pay is that it's
**      a bit cryptic, to say the least...  - kw
[...]         ^^^^^^^^^^^^^^^^^^^^^^^^^

It initially conformed to the HTMLPro DTD, but has been modified
considerably to TagSoupNess, so that it no longer conforms to any
DTD, and with no comments or explanations of when or why it does
or does not respect SGML principles, plus is so "cryptic" that what
it does with various markup more often than not can be determined
only by empirical testing.  It now is as "unmaintainable", IMHO,
as the development code's chartrans implementation.

        On the other hand, there are many things in the development
code and not v2.7.2 which are important to include in a v2.8 release,
e.g., the DOS/WIN/NT ports.  Those are still available to "field
testers" of the development code.  But we've just had a nominal
"release", and as I've stressed, Lynx will be wherever the development
code goes in its actual release.  If that's done now, with those serious
problems (IMHO) still not dealt with, you could end up doing more harm
than good for future Lynx useage.  No release can be expected to be
bug free, but sites which wait for a "release" to upgrade do so with
the expectation that the new features have been adequately field
tested and serious problems eliminated.  One can be a "loose cannon"
with words, just as with code.

        As usual, the current lynx-dev regulars should feel free
to shoot the messenger.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================