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

[Vlad Harchev]

On Tue, 11 Apr 2000, Klaus Weide wrote:

> On Tue, 11 Apr 2000, Vlad Harchev wrote:
> > On Mon, 10 Apr 2000, Klaus Weide wrote:
> > > I have to admit I forgot (or never understood) why Henry finds this as
> > > important as he does.
> > 
> >    Me too. 
> 
> Maybe he could remind us once more.
> 
> > > > 2) Complicating the syntax makes the use of various scripts and tools
> > > >    that edit or parse lynx.cfg very complicated and impossible.
> > > 
> > > All you can rely on with *existing* options is that they have the form:
> > >    <OPTION_NAME> ':' <content completely specific to the option>
> > > with only certain characters allowed in <OPTION_NAME>, and some minimal
> > > rules about the right side (like: there can't be newline chars).
> > 
> >    If values of the form 'FOO:A,B' are not used, then in most cases I can
>                                                          ============
> > assume that changing the string to the right of FOO changes the value. Also
> > for most options it's possible to enumerate allowed values (i.e. no regexp 
> > is 
> > necessary - just a list of allowed strings). If values
> > of the form FOO:A,B are allowed, 
> 
> They are already allowed, options with unusual values (that don't fit
> your "in most cases") already exist - not just SUFFIX_ORDER.

  Please give an example of options that accept the list of switches separated
with comma like SUFFIX_ORDER.

> > then when writing configuration tool, I have
> > to keep in mind that user can change only the part of the metavalue (change 
> > A
> > to C) so the right part should modified in some way to reflect change of A 
> > to 
> > C. This is unnecessary complication.
> 
> Not much different from all the FOO:a:b and FOO:a:b:c and FOO:a:b:c:d that
> already exist.  Come on, this isn't much extra work.

  Options like FOO:SUBFOO:A (like PRETTYSRC:comment:blah - i.e. FOO is
subscripted by 'SUBFOO') are easy to handle - just store 'PRETTYSRC:comment' 
as option name in the table of options the configuration tool supports. We
can't select syntax like this for SOURCE_CACHE stuff since we have to provide
backward compatibility (if compatibility wasn't the case, I would agree on
using something like
 SOURCE_CACHE:METHOD:FILE
 SOURCE_CACHE:FOR_ABORTED:DROP
but we can't since SOURCE_CACHE is already used.)
  Let's think in advance from this time.

> > > > 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.
> > > 
> > > No, it isn't the first time.  Try
> > > 
> > >    egrep '[A-Z_]+:[A-Z_]+,[A-Z_]+' lynx.cfg
> > 
> >   Only SUFFIX_ORDER matches this pattern. I don't think that this setting is
> > as important as SOURCE_CACHE is. The probability of user wishing to change
> > SOURCE_CACHE related things is (IMO) by several orders higher than the one
> > wishing to change SUFFIX_ORDER. The values between commans of SUFFIX_ORDER
> > configure one thing, while the variant you propose configure rather 
> > different
> > things.
> 
> They configure apsects of the "source cache".  Tee option is named
> SOURCE_CACHE, not just SOURCE_CACHE_KIND_OF_STORAGE or the like, ergo
> it's most logical that aspects of the "source cache" are configured
> with this option.  (That's *my* main reason why I would prefer this
> to be covered by SOURCE_CACHE.)

  Yes, this can make sense for human (but we are also programmers).

> > And as for SUFFIX_ORDER - there are a few allowed values for it, 
> 
> 1- same here.
> 2- the number of flags could grow.
> 
> > so each 
> > combination can be given another name without comma in it.
> >   In fact, I've written configurator for lynx for DOS. Current option naming
> > scheme allows to use table-based approach (option name, description,
> > validator function) for it, various (unnecessary) complications will result 
> > in
> > fewer (in theory) configuration tools for lynx.cfg.
> 
> I have no problem with the number 0.
> I do have problems with increasing the number to 1, if that means that
> it's suddenly more important that lynx.cfg is parseable by machines
> than by humans.
 
  I don't think that adding new toplevel option will  complicate lynx.cfg that
much (I don't propose redesigning format of lynx.cfg - I propose to just
respect on of the apporaches used for options in lynx.cfg).

> If I understand right what you are doing, you already need lots of
> option-specific validator functions for the existing options.  Just as
> there are lots of options which have (in LYReadCFG.c) CONF_FUN instead
> of CONF_BOOL etc.

  Fortunately, only a few are important, and the most important ones use
config_enum function (i.e. they map strings to ints). The syntax you propose
for SOURCE_CACHE won't be easily parsable, and there will be several UI
controls for the single option, and you'll have to preserve all original
'subvalues' of the option, etc.

> > > >  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.
> > >               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > 1.) Human readers should matter more than some hypothetical external 
> > > tools.
> > 
> >     human readers are easily configurable :)
> 
> There a xx thousands of users, on the one hand.  There is (maybe) one
> configuration tool for which one person must write an additional function
> or two, on the other hand.  Guess whose life I'd prefer to make a bit
> easier, if there is really such a choice to make.

   I understand your logic, but by adding new toplevel option the life of
users won't become worth that much.

> > >     The existing options all have their own syntax rules already, anyway.
> > >     For example, in some URL- or file-like options backslash is 
> > > interpreted
> > >     as an escape and in others not, sometimes whitespace is significant, 
> > > etc.
> > 
> >         How often do you expect user will change them? I don't think very
> > often.
> 
> So you are writing a configuration tool that works only for some options?
> Only for those you expect not to be changed "often"?

  Yes.
 
> > > >  I already proposed an approach to naming options - they should contain 
> > > > dots
> > > > and thus lynx.cfg will look like X resources file, e.g.:
> > > 
> > > ...and be just as confusing to the average person.
> > 
> >   Probably. But only you replied to that proposal (may be others have
> > different opinions).
> 
> I repeat, I find that would introduce ugliness without real benefit.

  This is my point to, but to your position.
  There is a solution that can satisfy both POVs:introduce new CACHE_SOURCE
option with two suboptions named 'METHOD' and 'FOR_ABORTED'. SOURCE_CACHE will
be deprecated but supported for the rest of time.
 
>    Klaus
> 

 Best regards,
  -Vlad