[webkit-dev] Curl Cookie Handling

[Kevin Ollivier]

Hi Julien,

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

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.

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

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

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.

Thanks,

Kevin

>
> Regards,
> Julien