On 22 February 2012 05:33, Troels Henriksen <athas_AT_sigkill.dk> wrote:
> Peter Hartman <peterjohnhartman_AT_gmail.com> writes:
>
>>> This is still is favorable than the current approach as far as I can tell.
>>
>> Why?
>
> Because in Surf as it is now, cookies are not readable from Javascript,
> and an increasing number of sites rely on this being possible. The
> naive approach used in sb is not by itself useful (as already mentioned
> by Calvin Morrison), and I just haven't been motivated enough to do the
> heavier glib programming necessary to do a proper integration. As I
> remember my analysis, you can't use cookie-changed signal, though, as it
> is not sent when the file changes, but rather when the cookie object
> changes (and I think the file is automatically rewritten when that
> happens anyway). Rather, I think we will need to create an object from
> scratch that implements the cookie jar interface, but which uses the
> current mechanism of completely re-reading the file whenever a cookie is
> requested or given. (Nothing should prevent us from using inotify to
> be a bit smarter, though.)
This is sort of where I ended up at the end of the day. I wonder if it
wouldn't be better to patch libsoup and send it upstream. Modifying
the SoupCookieJarText [1] session feature to wait on file changes and
push a new file-updated signal seems like a pretty sane approach.
But, since we write out to the cookie jar frequently, wouldn't it be
inefficient to be constantly re reading (and reparsing) the entire
cookie file?
Just thinking out loud,
Calvin Morrison
[1]
http://git.gnome.org/browse/libsoup/tree/libsoup/soup-cookie-jar-text.c
Received on Wed Feb 22 2012 - 14:32:48 CET