I would definately be interested in this work for my EFL port of WebKit. Currently we use cURL and do not support cookies. Libsoup is apparently a no-go as I was told that it requires a running glib mainloop.
Cheers, Kenneth On Tue, Feb 10, 2009 at 12:08 PM, Julien Chaffraix < [email protected]> wrote: > 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 >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
