After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 648972 - registry: add/remove functions inconsistency
registry: add/remove functions inconsistency
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-04-29 18:50 UTC by Thiago Sousa Santos
Modified: 2018-01-23 00:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
tests: registry: Adds test to manually remove plugins from registry (1.83 KB, patch)
2011-04-29 18:50 UTC, Thiago Sousa Santos
reviewed Details | Review

Description Thiago Sousa Santos 2011-04-29 18:50:35 UTC
I don't know much about the gstregistry code, but I was writing some tests
that emulate missing plugin situations and I noticed a inconsistency on the
removing and adding of plugins. The attached test shows the problem.

From what I understand, adding a plugin doesn't register its features
automatically. I'm wondering if we shouldn't do that, or why it isn't done
currently.
Comment 1 Thiago Sousa Santos 2011-04-29 18:50:37 UTC
Created attachment 186898 [details] [review]
tests: registry: Adds test to manually remove plugins from registry

Adds a test that checks that removing and adding plugins manually
to the registry works
Comment 2 Sebastian Dröge (slomo) 2011-05-03 07:18:17 UTC
If you automatically load all plugins that are added to the registry you will always load all plugins that exist on the system and not only the ones that are currently needed.
Comment 3 Thiago Sousa Santos 2011-05-03 14:39:06 UTC
If I understand correctly, the plugins have features, and at least the features names need to be put into the feature -> plugin map, so they can be found from gst_element_factory_make for example.
Comment 4 Sebastian Dröge (slomo) 2011-05-03 14:51:18 UTC
Yes that would make sense but gst_plugin_load() should be prevented
Comment 5 Sebastian Dröge (slomo) 2011-05-17 06:56:07 UTC
So how do we want to proceed here? :)
Comment 6 Sebastian Dröge (slomo) 2014-01-18 13:59:02 UTC
Thiago?
Comment 7 Thiago Sousa Santos 2014-01-20 13:07:28 UTC
The problem persists in 1.0. The issue is that gst_registry_remove_plugin removes the plugin and its associated features, but gst_registry_add_plugin just adds the plugin without reloading the features. So the remove/add pair is a bit
asymmetric.

I'm not sure how (and if we want) to fix this. I haven't touched gstregistry code ever, so I don't know the details. The use case I had was for testing behavior of camerabin when some elements were missing.

IMHO we should at least mention at the _add_plugin documentation mention that it won't automatically add the plugin features back and maybe add an explicit function for loading the plugin features, as the GstPlugin is opaque and gives the user no access to GstPluginDesc that has the init function pointer.
Comment 8 Sebastian Dröge (slomo) 2014-01-20 14:33:52 UTC
Yes, at least document it. IMHO these should be symmetric but doing that without breaking (or only minimally breaking) backwards compat needs some discussions :)
Comment 9 Tim-Philipp Müller 2018-01-23 00:37:13 UTC
Closing this to reduce clutter in bugzilla.

Not sure if we really need to do anything here.

_add_plugin() is usually called internally by GStreamer.

Feel free to improve the docs as proposed, or re-open :)