[webkit-dev] Curl Cookie Handling
kevino at theolliviers.com
Tue Feb 10 11:57:35 PST 2009
On Feb 10, 2009, at 7:08 AM, Julien Chaffraix wrote:
> Hi Kevin,
>> Is this patch still valid, i.e. not made obsolete by another
> As far as I know, there is no work towards storing the cookies inside
> the database as it is done in Firefox. Furthermore I know no work in
> cURL toward exposing the cookies so that we could add / remove /
> update them simply in our database.
> This patch may be a bit special because it is not really cURL
> specific. The only dependency to cURL is a method to parse a date (the
> would need to be exported to WebCore and maybe need to be adapted.
> Thus it could be a base toward a cross-platform cookie implementation.
> I do not know if it would be ok for all ports to replicate their
> network library's cookie engine.
Well, each port could of course decide for themselves. I know wx would
like to use this. :-) I wonder if the GTK or other ports are also
interested? Maybe they should voice their support if so.
>> was it a complete patch (sans any bugs, of course) for cookie
>> support using
>> SQLite? I could only test it using wx right now but I would
>> definitely be
>> interested in using the SQLite approach.
> It is a complete patch in the sense that it stores and fetch the
> cookies from the database. About the bug-free part, we have an answer
> in this thread I guess :-)
> Basically I could not find a test suite for cookies to validate the
> approach when I started so I tested it with real world websites
> (mostly google app suite, yahoo, mapquest and a few other sites) but
> it did not get the testing it deserves and I will not hide it.
Yes, I did look at your patch earlier but I myself wasn't confident
that I'd know how to properly test cookie support, so I hoped someone
more knowledgeable would step in. :(
> To get it moving, I think a rewrite is necessary because I made tons
> of small mistakes (I started as a contributor at that time and did not
> know the code and coding conventions as I do now) that could be more
> easily tackled by a rewrite. It will also need a test suite to fully
> valide the changes.
> All in all, it means a lot of work that I am willing to do it *if* I
> see enough interest in a cross-platform cookie engine for WebKit.
Well, knowing this project, I doubt you'll find anyone who would
object to starting a series of unit tests for cookies. :-) From there,
it is a matter of reworking your patch, but I can say if there is a
test suite I can run that handles common usage, I'll feel a lot more
comfortable reviewing your patch.
>> I know someone a while back proposed a strategy for dealing with port
>> enhancements that end up bit rotting in the review tree, whatever
>> to that? Sometimes new feature patches cannot be broken down into
>> pieces, and I realize large patches tend to be intimidating
>> especially to
>> people who can't test them themselves, but there has to be some
>> strategy for
>> dealing with that so that important new stuff doesn't just sit in a
>> tracker for months or years...
> I think you refer to the Gtk port here? IIRC the main issue for Gtk
> was validating the API which is not relevant here.
That sounds familiar, I guess I mistook the discussion to be about
"port specific" rather than "API specific" patches. Still, I think
there ought to be some recourse when a patch submitter cannot find a
willing reviewer after some long period of time.
More information about the webkit-dev