[webkit-dev] Curl Cookie Handling

[Julien Chaffraix]

Hi Kevin,

> Is this patch still valid, i.e. not made obsolete by another approach?

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
'max-age' field), which I found later is already in JavaScriptCore and
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.

> Also,
> 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.
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.

> I know someone a while back proposed a strategy for dealing with port
> enhancements that end up bit rotting in the review tree, whatever happened
> to that? Sometimes new feature patches cannot be broken down into smaller
> 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 patch
> 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.

Regards,
Julien