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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
