[gstreamer-bugs] [Bug 350477] New: [Registry] Provide a way for plugins to delegate the 'changes' behaviour

[GStreamer (bugzilla.gnome.org) <bug...@bu...>]

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=3D350477
 GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: [Registry] Provide a way for plugins to delegate the
                    'changes' behaviour
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gst...@li...
        ReportedBy: bi...@bi...
         QAContact: gst...@li...
                CC: wi...@po..., bi...@bi...
OtherBugsDependingO 304361
             nThis:
     GNOME version: Unspecified
   GNOME milestone: Unspecified


+++ This bug was initially created as a clone of Bug #304361 +++

 Comment #4 from Edward Hervey    (developer, points: 16)
2006-04-29 16:50 UTC [reply]

A couple of ideas on this, since creating elements with gst-python is get=
ting
easy and interests a lot of people.

With the current way the registry works, we need a few additions to it.
Currently the registry will check if the size/time of the .so has changed
before trying to re-read the information contained in it. This is going t=
o be
problematic, since the python plugin .so will not change, but the python =
files
might have.
We therefore need a way to indicate that some GstPlugin handle that 'file=
/time
has changed' feature.
How the plugin informs that (none/some/all of the python files it supervi=
ses
has changed) to the registry is still uncertain. Maybe it could compute a=
 hash
that would be stored in the registry and compared on successive runs.

On another side, it might make more sense having this plugin code in the
gst-python module since you will need gst-python anyway, and you are sure=
 to
have Python. This would keep core/-base lightweight.


Comment #5 from Benjamin Otte (Company) (reporter, points: 17)
2006-04-30 11:20 UTC [reply]

This is a problem that is not unique to the Python loader - nor to loader=
s for
other languages. The LADSPA plugin for example can have new plugins witho=
ut its
.so changing. An ffmpeg plugin that depended on an external ffmpeg would =
be
another example.

The easiest solution I had in mind was having a flag that marked plugins =
as
"must-load". Another possibility would be to have a special dir (say
$(plugindir)/autostart ;)) where you put (preferrably small) plugins.

Then all you need to do is put a libgstcheckpython.so there that checks i=
f new
python stuff is available and if so, makes the registry load libgstpython=
.so.
That way you'd get around loading the Python interpreter in every program=
 but
would still be sure you didn't miss anything.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.