Re: lynx-dev Cookies and command line operation

[Vlad Harchev]

On Sat, 30 Oct 1999, Klaus Weide wrote:

> On Sat, 30 Oct 1999, Leonid Pauzner wrote:
> > 29-Oct-99 20:48 Klaus Weide wrote:
> > 
> > > So here's a somewhat different idea: A 'save_cookies' flag that
> > > tells lynx whther to *write* cookies to file or not.
> > > In interactive mode, default is
> > >  - ON if persistent cookies are enabled
> > >  - OFF if persistent cookies are disabled
> > > In noninteractive mode, default is
> > >  - OFF
> > 
> > I think this is a very useful approach: always *read* cookies_file
> > (when cookies are ON),
> 
> When (1) cookies are ON, or (2) when PERSISTENT_COOKIES are ON, or
> (3) when cookies are ON *and* PERSISTENT_COOKIES are ON?
> 
> My idea was (2).
> 
> Actually there isn't currently really one "cookies are ON/OFF"
> setting.  There is SET_COOKIES which controls receiving (accepting)
> of cookies in general, it doesn't affect the sending side of cookie
> precoessing directly (you may still be sending cookies if SET_COOKIES:
> FALSE but PERSISTENT_COOKIES:TRUE, see comments to SET_COOKIE in recent
> lynx.cfg).  Inconsistently, -cookies is the command line option that
> corresponds to SET_COOKIE, but -cookies=off still doesn't turn all
> cookie processing off, only the receiving-of-Set-Cookie side.
> 
> (I'd appreciate if someone would check whether that's actually all
> true and not just my understanding...)
> 
> >                        but write to cookies_file conditionally;
> > this is much better than current "PERSISTENT_COOKIES:TRUE/FALSE"
> > behaviour. One could be a command line toggle
> > and probably lynx.cfg option (instead of PERSISTENT_COOKIES:
> > 
> > in this particular case I feel it is not bad to break backward compatibility
> > with naming convention - persistent cookies were experimental anyway.
> > And EXP_PERSISTENT_COOKIES could now be renamed to PERSISTENT_COOKIES 
> > symbol:)
> [ second attempt ;)]
> 
> My idea was to require a change from -dump users that want cookies
> saved (they need to set one additional flag/option), not from
> interactive users.  I think that's more acceptable.
> 
> But if you find that, for the sake of clarity, it's worth
> inconveniencing more of the current users, let's discuss it further.

  IMO it's worth breaking backward compatibility.
 
>      Klaus
> 

 My POV on all this is to have commandline and lynx.cfg flags like
'save-cookies-to=file' and 'read-cookies-from=file' (several such args could 
be specified) if EXP_PERSISTENT_COOKIES is defined, plus 'accept-cookies' 
(so user will be able to browse them) and 'send-cookies' (sending
cookies that are present in the jar, jar is formed by cookies read from
files and by accepted cookies). In order to support non-unixes, '/dev/null'
should be treated with its unix sense on all platforms. IMO these options will
provide full control over cookies. Cookie file locking can be implemented too.

  Don't be  scared by more comandline and lynx.cfg options - flexibility is
more important. Ability to read from several files, and ability to write to the 
given file will be preffered.
In ideal case, some utility like 'cookie' should be written too, possibly
distributed outside lynx (probably written in perl), that will:

* dump all cookies that are required for a given url
* validate cookies specified on commandline
* dump valid cookies for a given day and given url pattern
* union several files with cookies
* convert between various file formats storing the cookies (MS, NS, lynx,
   Opera (if it uses cookies)?).

IMO writing generic things is preffered, than burning them into lynx.

 Best regards,
  -Vlad