[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