[Bug 748452] System registry cache file

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748452

--- Comment #6 from Dan Nicholson <nicholson at endlessm.com> ---
(In reply to Tim-Philipp Müller from comment #5)
> 
> I didn't re-read the code in detail just now, but I'm not sure if the (my)
> comment in gstplugin.c why we store the environment variable hash is
> correct. One purpose of the hash is to trigger rescanning of a plugin when
> certain environment variables change. Example: we have a wrapper plugin
> around a library that itself has plugins and the FOO_PLUGINS_PATH env
> variable determines where that lib should look for additional plugins. Now
> if someone sets or changes FOO_PLUGINS_PATH that might cause the foo
> gstreamer wrapper plugin to expose a different set of elements, so this
> plugin should then be reloaded in this case.

Yes, it took me a little while to understand, but I agree that's the purpose.
The thing is, you always have to run the dependency scanner regardless because
you need to find out if anything in the paths changed. And the dependency
scanner has to resolve the environment variables itself (it actually does a
much more thorough job than the hashing). So, the environment variable hash
seems to me to be completely useless.

Case 1: FOO_PLUGINS_PATH is unchanged from before. You don't know what the
actual value of the variable is from the hashed value, so you have to resolve
it again anyway. Now you actually have to go look in the path to stat all the
directories and files.

Case 2: FOO_PLUGINS_PATH did change from before. You resolve the values and go
stat all the directories and files just like case 1.

So, I feel pretty confident that the variable has is not adding any value. If
you drop it, you just immediately jump to resolving the variables and scanning
the paths they point to, just like always happens now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.