[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev SOURCE_CACHE "problem" - proposal of SOURCE_CACHE_FOR_IN

From: Vlad Harchev
Subject: Re: lynx-dev SOURCE_CACHE "problem" - proposal of SOURCE_CACHE_FOR_INCOMPLETE
Date: Mon, 10 Apr 2000 10:31:12 +0500 (SAMST)

On Mon, 10 Apr 2000, Henry Nelson wrote:

> > anyway, Vlad seems to be much more interested and he knows where to
> > do it.
> Vlad, I beg you to have a bit more pride in your work and not show me
> some of the rather sloppy hacks I've seen in the past.  I don't buy your
> argument about "too complicated and requires too much work to implement"
> as for the sub-options in lynx.cfg, nor the one about "can't use an
> external proxy in DOS."

  Did I mention "external" explicitly in that message? If yes, please ignore 
it. If user is connected via 14.4K modem and uses lynx for DOS, then it makes 
no difference on whether external proxy is used or not - compared to the speed
source cache lynx provides.

 As for sub-options in lynx.cfg - I think that 
1) Complication of code that parses suboptions in a way Klaus propsed, e.g.
   FOO:A,B - is totally unnecessary compared to the net effect it gives - 
   just getting rid of new toplevel option.
2) Complicating the syntax makes the use of various scripts and tools
   that edit or parse lynx.cfg very complicated and impossible.
3) Hiding several suboptions under one toplevel option decreases the
   flexibility of extended INCLUDE syntax.
4) This is the first precedent of complicating things in that way (FOO:A,B) - 
   suboptions were implemented as FOO:A:V1 and FOO:B:V2 before. I don't want
   to make the broken syntax as FOO:A,B normal.

 As for pride in my work - I'd better spend time on hacking some other Open
Source project (a lot needs hacking alas) rather than turning the syntax of
lynx.cfg in completely unparsable by external tools.

 I already proposed an approach to naming options - they should contain dots
and thus lynx.cfg will look like X resources file, e.g.:


 These two options are really toplevel (they will be registered as a separate
entries of a table in LYReadCFG.c), but they look like subopions of
SOURCE_CACHE for a human

 But AFAIR only  Klaus replied and said that this approach should have been
used from the very begining and it's too late to use it now.

 I state that I will implement only toplevel option for this feature (no
suboptions for this). It's up to Tom to (not)include/edit the patch I will

> __Henry

 Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]