[Bug 761099] http: cookies sharing in the pipeline

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Dec 1 11:09:08 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=761099

--- Comment #13 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Thiago Sousa Santos from comment #11)
> (In reply to Sebastian Dröge (slomo) from comment #10)
> > Just some comments about the API:
> > * gsthttpcookiejar.h:
> >   - The "gpointer author" in the changed signal / add is not very bindings
> > friendly. GObject*? GValue (then you could also use boxed types)? With the
> > gpointer, how is ownership even handled?
> 
> The idea here is just for users to be able to ignore changes caused by
> themselves. Suppose you add a cookie, you will get a 'changed' signal.
> Looking at the author you can check that it was yourself and ignore that
> change. Otherwise you should get that new cookie and add it to your local
> store. Any ideas on how to solve this with bindings friendly parameter? Just
> use GObject*? This will make all users of the GstHttpCookieJar need to be a
> GObject, but we expect that it would be GstElements using it.

Understood. I'd make it a GObject* and store a (weak?) reference then,
everything else just seems weird.

> >   - GSList* is ugly too
> 
> Do we have a bindings friendly list? Or is it more common to have a _size()
> and _nth() function pair?

GPtrArray / GArray maybe? In most cases it's also more efficient than a linked
list, not sure if here.

Depends on what kind of operations are supposed to be done on this list.

> >   - What about some API to get all cookies for a specific domain, so have
> > the filtering-code in one specific place instead of having to duplicate it
> >   - API to expire all cookies that are expired now?
> 
> I was trying to avoid having all cookie related functions inside this lib.
> It should serve mostly to unite cookies from different worlds (webkit and
> soup). The elements would actually be using the functions provided by those
> more complete libraries and the changes they do there should propagate to
> our library so that they can also be replicated on other cookiejars. I don't
> see a need to do that from gstreamer code just yet.

Ok, can be added when needed. Just don't add code for that in every single
plugin that uses this API ;)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list