[gst-devel] gst-register

[Daniel Stodden]

On Thu, 2004-10-21 at 19:11 +0200, Thomas Kuleßa wrote:
> Am Do, den 21.10.2004 schrieb Daniel Stodden um 15:46: 

hallo.

> > there is already a huge number of prepackaged plugins available. apt-get
> > one or all, cd to /var/lib/dpkg/info. grep for gst-register and copy the
> > relevant parts from the .postinst and .postrm scripts.
> These are all part of the "offical" gstreamer plugin release. So they
> are all in /usr/lib/gstreamer/. Sure I can put my plugins there too, but
> what's the point of a registry if everything goes to the same place
> anyway?

i guess the major point is that you do not have to dlopen 145+ binaries
over and over again each restart just to figure out that two of three
desired elements still reside within the same module.

> gst-register has a "--gst-plugin-path" parameter (which isn't used in
> the postinst scripts your are refering to) exactly for this...
> as far as I understand it. 

actually judging from what it's doing right now, it's should be called
'cache'.

> > i must admit i'm not aware whether it's possible to
> > 
> > b) install to a private location, create a private registry and merge
> > that with the global one at runtime.
> > 
> > 
> > 
> At the moment each call of "gst-register" recreates the registry 
> completly. Perhaps "gst-plugin-init" would be a better name.
> Do you see my point? 

do you see mine? the registry is for domain-wide plugin localisation.
(that's not the official term). what i call a 'domain' is installing
system wide or installing per-user. installing per application would be
a hybrid and you need 'huge' applications, actually a whole suite of
applications, the photoshop of gstreamer, to benefit from that.

> At the moment you would have to keep track
> of all your "gst-register --gst-plugin-path=..." calls, 
> otherwise a "registration " call erases previous "registrations".

right. that's why people either:

a) create a reusable plugin/element useful for a number of applications
   and install to the standard path. call gst-register.
b) create a private application-specific element and
   link it into an application as a regular object file.
   simple, efficient, fail-safe.
c) you're writing a package with three executables based on common
   elements. you can:
 i) create an .so, set -Wl and install to /usr/lib/mypkg/.
    you don't need the plugin_register stuff. just call into the
    library with g_object_new() or a custom constructor.
 ii) still insist on calling it a plugin because of all 
     the karma dlopen() spreads or something.
     well, you still do not need to look it up.
     you know where the element resides because you compiled it.
     you know the path where to load it from because you
     installed it. have a look at gst_plugin_load_file().
     (i didn't try it, just looked it up)
 iii) still you're unhappy. you want to load a
      private registry because it looks more dangerous 
      (and is). then have gst look it up just to see
      whether it comes up with the solution you already knew.
      okay, write an option for gst-register to build xml ignoring
      system-wide plugins (can't be done right now afaik). then
      make it load both both the up-to-date system-wide
      registry (managed by dpkg) for the base stuff you depend
      on and the static, private one on top of that. (don't know whether
      that works out of the box).

a 'plugin' is a bunch of reusable resources developed and deployed in a
distributed fashion. a plugin does not equal an element. an element does
not depend on plugins. registries are only needed where it all comes
together.

:)

kind regards,
daniel

-- 
Daniel Stodden
LRR   -   Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU Muenchen       D-85748 Garching
http://wwwbode.in.tum.de/~stodden     mailto:stodden at in.tum.de
                                                            --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20041022/2824292e/attachment.pgp>