Re: LYNX-DEV Re: Multibookmark patch

[Foteos Macrides]

address@hidden (Drazen Kacar) wrote:
>Filip M Gieszczykiewicz wrote:
> 
>> Greetings. Sorry for taking this out of context. I was wondering:
>> since you did not object so strongly to my multi-bookmarks patch,
>> does that mean that there is even a small sliver of a chance that
>> it will make it into official release? I've used the current version
>> for a few weeks now and it appears to work well. Some people,
>> sys-admins included, complain that if it's not "official" they don't
>> want to apply it... so it would greatly help if it was, indeed, 
>> official. Besides, as long as the user is "Novice" it works just
>> like it does now - even "Advanced" has that option... just has
>> some room for expansion.
>> 
>> Pretty please? [seriously]
>
>I've looked at the code two revisions ago and I don't know how it looks now,
>but here are my objections to that code:
>
>  - having number of multi bookmarks in #define is no good. You were just
>    dumping a menu on the screen regardless of screen size.
>  - there was no testing of screen width for printing out particular bookmark
>    definition. Just dumping it out and hoping that screen width is big
>    enough.
>
>There were some others, but I can't remember any more.

        But to answer the original question, generically, the
multibookmark patch is *not* it the same category as the patch
for making the current document's URL in the showinfo display
a forward link, with all the complications and overhead that
invokes, when all it ultimately achieves can already be done,
cleanly, simply by pressing any of the PREV_DOC command synonyms
(e.g., left-arrow).  It would not be in the Lynx community's
long-term best interest to include misguided patches that
would move Lynx back toward a hodge-podge of ill-coordinated
code.

        It is highly desireable for Lynx to support a hierarchy
of bookmark files directly, rather than just indirectly via
hand editing of a single bookmark file, or by manually entering
each bookmark file's name via the 'o'ption menu.

        It's not clear, at this time, how best to achieve that
objective, and the best way can't be determined until it's more
clear whether any major changes in the Lynx API will be undertaken
soon, and in turn how to redesign the now overloaded 'o'ptions
handling.  In the meantime, that patch still needs work, and
you're doing a good job of supporting it, plus gaining hands-on
experience developing and supporting Lynx, so another pressing
need (more people who have hands-on experience both developing
and supporting Lynx) *is* being served.

        A third category was the patch for allowing 301 or 302
redirection to be treated as a 303.  It would have been better
(IMHO) to keep that as a patch which extends the base of people
with hands-on experience developing and supporting Lynx, rather
than my just taking it as it stood and including it with the
minimally required tweaks.  But...  without it the basic objective
of "better than nothing" information sharing would not be met by
Lynx v2.6 for a still goodly number of deployed CGI scripts.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;