Re: lynx-dev Cookies and command line operation

[Klaus Weide]

On Wed, 20 Oct 1999, brian j pardy wrote:
> On Wed, Oct 20, 1999, Klaus Weide wrote:
> > On Wed, 20 Oct 1999, brian j pardy wrote:
> > > I don't have 2.8.1rel.2 source breakout sitting around,
> > 
> > There's always the breakout directories on sol.slcc.edu for convenient
> > checking of a previous version's single file...
> 
> Ah, I didn't check, but didn't think they'd be around from a few
> versions previous.  Thanks.

There are several, but you may have to "guess" the directory names
(find link to latest release's breakout, then make the obvious
version changes in the URL - 'G' and 'E' are a good thing...).

> > Start with <http://www.flora.org/lynx-dev/html/month0699/msg00444.html>,
> > follow the pointer.  It will take some reading of messages.
> > 
> > I don't know why nobody has added code that solves the problem, it
> > shouldn't be any more difficult than what's already being done for
> > other cases.
> 
> Wow.  I can't believe I forgot about that, and consistently kept
> forgetting about it.
> 
> I'll see what I can come up with based on your analysis in there. 
> 
> Can we get some discussion from anyone else interested on your
> comments below?

It seems nobody is much interested, folks just want to use cookies
(or should that be passive voice) and not think about them...
<strike comment="on second thought"
<rant>
</rant>
</strike>

> > I haven't done it because
> >    - I don't use cookies much, basically only for testing.
> >    - I have no need for saving cookies with -source, even
> >      some doubts whether lynx should do it.
> 
> As you mentioned in [0], perhaps another commandline flag for this.  I
> think that would be most proper, but it's a gut feeling sort of thing
> and I don't have any real reasons either way.

> [0] http://www.flora.org/lynx-dev/html/month1298/msg00514.html

I've thought about it a bit more.  An additional
-persistent_cookies_with_dump (or whatever name) flag just for
(-dump/-source) is ugly.  There are already many flags that have only
effect in one mode (noninteractive vs. interactive) and get ignored in
the other, let's try to avoid adding another one here if we can provide
something instead that's useful in both modes.

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

This would allow to *use* the cookies in a cookie file as-is, without
messing with it, i.e. a "read-only cookie jar" for interactive use.
Say you have accumulated cookies form some sites you trust, they don't
get frequently changed, and you want to hang on to that state of the
jar.  Cookie files could be shared between several sessions without
risk of overwriting each other's state.  (could even be shared between
several users or system-wide if you feel like it...)

I think now we should only distinguish (for purposes of this flag)
between interactive and noninteractive, i.e. treat -dump and -source
(even -mime_header) the same, as well as -dump implied by -get_data
and -post_data.  I think now that the difference between -source and
-dump that I brought up earlier isn't really worth bothering, it is
theoretical only: I have never seen "Set-Cookie" used in an HTTP-EQUIV
META tag in real pages.

I am not sure whether this should be command line flag, lynx.cfg option,
or both, but probably both.

What do you think?  (And what do the consumers-of-cookies think?)

An extension of the above, for even more flexibility, would be to have
a -cookie_write_file (or -cookie_save_file) separate from the normal
-cookie_[read_]file.  By default they would be the same (for
interactive use).  This would make the option proposed above
unnecessary, because its behavior is included as
-cookie_write_file=/dev/null (which would be the default for
noninteractive invocation).  The only thing I find ugly about it
is that "/dev/null" is an OS-specific convention.

> >    - I would want to review whether lynx should really call
> >      exit_immediately from withi  HTFWriter_free, I consider
> >      that unclean.
> 
> I expect I'll agree with you when I inspect the code.

Just changing the code to allow it to return normally instead of
exiting should show some message(s); suppression of that/those
is the reason for exiting immediately, as far as I can guess.

Well it works, it's just ugly (and may lead to similar surprises
again when other folks add code that needs some cleanup before
exit).

> My apologies for being exceedingly dense in forgetting about your
> analysis.

Well, if I remember right you are not a big user of cookies either,
so it isn't really your problem...


   Klaus