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.<br><br>Cheers,<br>
&nbsp;Kenneth<br><br><div class="gmail_quote">On Tue, Feb 10, 2009 at 12:08 PM, Julien Chaffraix <span dir="ltr">&lt;<a href="mailto:julien.chaffraix@gmail.com">julien.chaffraix@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Kevin,<br>
<div class="Ih2E3d"><br>
&gt; Is this patch still valid, i.e. not made obsolete by another approach?<br>
<br>
</div>As far as I know, there is no work towards storing the cookies inside<br>
the database as it is done in Firefox. Furthermore I know no work in<br>
cURL toward exposing the cookies so that we could add / remove /<br>
update them simply in our database.<br>
<br>
This patch may be a bit special because it is not really cURL<br>
specific. The only dependency to cURL is a method to parse a date (the<br>
&#39;max-age&#39; field), which I found later is already in JavaScriptCore and<br>
would need to be exported to WebCore and maybe need to be adapted.<br>
Thus it could be a base toward a cross-platform cookie implementation.<br>
I do not know if it would be ok for all ports to replicate their<br>
network library&#39;s cookie engine.<br>
<div class="Ih2E3d"><br>
&gt; Also,<br>
&gt; was it a complete patch (sans any bugs, of course) for cookie support using<br>
&gt; SQLite? I could only test it using wx right now but I would definitely be<br>
&gt; interested in using the SQLite approach.<br>
<br>
</div>It is a complete patch in the sense that it stores and fetch the<br>
cookies from the database. About the bug-free part, we have an answer<br>
in this thread I guess :-)<br>
Basically I could not find a test suite for cookies to validate the<br>
approach when I started so I tested it with real world websites<br>
(mostly google app suite, yahoo, mapquest and a few other sites) but<br>
it did not get the testing it deserves and I will not hide it.<br>
To get it moving, I think a rewrite is necessary because I made tons<br>
of small mistakes (I started as a contributor at that time and did not<br>
know the code and coding conventions as I do now) that could be more<br>
easily tackled by a rewrite. It will also need a test suite to fully<br>
valide the changes.<br>
All in all, it means a lot of work that I am willing to do it *if* I<br>
see enough interest in a cross-platform cookie engine for WebKit.<br>
<div class="Ih2E3d"><br>
&gt; I know someone a while back proposed a strategy for dealing with port<br>
&gt; enhancements that end up bit rotting in the review tree, whatever happened<br>
&gt; to that? Sometimes new feature patches cannot be broken down into smaller<br>
&gt; pieces, and I realize large patches tend to be intimidating especially to<br>
&gt; people who can&#39;t test them themselves, but there has to be some strategy for<br>
&gt; dealing with that so that important new stuff doesn&#39;t just sit in a patch<br>
&gt; tracker for months or years...<br>
<br>
</div>I think you refer to the Gtk port here? IIRC the main issue for Gtk<br>
was validating the API which is not relevant here.<br>
<div><div></div><div class="Wj3C7c"><br>
Regards,<br>
Julien<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br>