[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Suggestion: cookie improvements
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-01-24 20:33:37
[Download RAW message or body]

On Tuesday 23 January 2001 19:12, Waldo Bastian wrote:
> On Tuesday 23 January 2001 13:32, Dawit Alemayehu wrote:
> > Again already there now, except for the ability to edit the expiration
> > date
> >
> > :) That seems to be the most request feature.  Yours is a bit different
> > : in
> >
> > that you want it to be editable from the "Alert" box which IMO is wrong.
> > But making it modifiable from the cookies managent dialog might be an
> > option...
>
> Hm.. the problem with this stuff is that it should be easy to do. You don't
> want to go to the cookie management dialog only to change the expire date
> after you just received a cookie. E.g. if the expire date in the verbose
> alert box is editable (and selected once you enter the lineedit) you can
> with relative ease change the expire date of cookies that you receive...
> especially if that lineedit will understand expressions like "4 hours", "1
> day" or "2 weeks".

Okay.  We can do this, but I will hold it off until 2.2 since I am working on
something else now or it is something Keunwoo wants to look into...  It should
be simple enough to accomplish...

> > > + Distinguish between accepting cookies and sending them.  User may
> > > wish to send previously set cookies by some domain, but not accept new
> > > ones.
> >
> > Hmmm... this indeed is a valid point and something to consider for later
> > as well...
>
> Current settings mostly apply to receiving cookies

Ahh right.  Sending always works unless you disable the cookiejar.

BTW that currently does not work properly either.  That is if you start browsing
and then disable cookie support the io-slave already running are not affected.
The solution to this is to move the cookiejar config into kioslaverc, since it belongs
there anyways, and add a couple of methods to obtain cookie config information.
This way when a user changes some config stuff we can simply send a 
reparseConfig which should update everything ( the cookiejar, the http-ioslaves...).
What do you think ?  This can ofcourse be easily done with backward compatability
in mind...

> i don't think existing cookies will get deleted when you choose not to
> receive any more cookies from a domain.

No it does not.

> > > + Distinguish between allowing server cookies and JavaScript cookies
> > > (the latter can be used to track behavior within an already-loaded
> > > page...).
> >
> > This is doable as well.  Just an extra field...
>
> But for each option that gets added this thing gets more complex and
> therefor harder to use. Is this so important that it justifies the extra
> complexity? (That's not limited to cookies btw)

Wait until you see what I have done to the http io-slave :) Just kidding,
but you are right I guess we have to watch out for a feature bloat...

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]