[gstreamer-bugs] [Bug 392393] [API] add libgstbaseutils library for missing plugins messages and unified descriptions

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=392393

  GStreamer | gst-plugins-base | Ver: HEAD CVS


Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #79304|none                        |needs-work
               Flag|                            |




------- Comment #6 from Tim-Philipp Müller  2007-01-08 18:09 UTC -------
Thanks for the review.

> * base-utils.h should include descriptions.h and missing-plugins.h as
> <gst/utils/base-utils.h>, because they're all installed headers

True, will fix (odd that it didn't cause problems).


> * Why force the user to include descriptions and missing-plugins via
> base-utils?

No particular reason, will fix.


> * The descriptions.h functions, look good... but is it a
> good idea to drop the base_utils bit and use the
> 'GstElement' namespace for the
>      gst_element_post_missing_
> functions? I don't know if this has any implications for
> autogenerated bindings. They're not GstElement member
> methods, so I don't think they should use the namespace,
> but...
>       gst_base_utils_element_post_missing_*
> is just getting silly. Leaving out bad too though.
> Perhaps we can come up with shorter function names for
> those methods, or alternatively, remove the post_element
> part of the functionality to put the methods into the
> gst_missing_plugin_message namespace, and make the caller
> then do gst_element_post () after. Bah, I dunno :) It's
> mostly the bindings part that bugs me - these functions
> shouldn't/can't end up as methods of GstElements in
> Python/C#/Perl/C++ and friends, so they shouldn't go into
> that namespace. 

I agree, but couldn't really think of better names either. Didn't know it might
be an issue for bindings.

I thought about just providing functions to create the messages as well, so
let's do that then. Just need to find good function names now...



> * I'm not sure about 'utils/' as an include path, but I
>   can't thinkof any real objection except that it's more
>   generic than our existing gst/ subdir examples:
>   audio, base, cdda, check, controller, dataprotocol,
>   floatcast, interface, net, netbuffer, riff, rtp, tag, video

I chose the generic name for the library on purpose. IMHO there's lots of stuff
that we're replicating all over the place in plugins that we might want to put
into a general utility library like this, but that shouldn't end up in core
(e.g. base64, misc. hash functions, basic abstraction for win32/unix sockets,
etc.). 

Would you prefer base-utils/ or baseutils/ as an include path instead?



> * Still needs docs hooks in the sections.txt file.

Yes, left that out on purpose while the API isn't final yet. I will add that
once the API is aggreed upon.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email