[gst-devel] Re: [gst-cvs] thomasvs gstreamer: gstreamer/gst/ gstreamer/gst/registries/

[Andy Wingo]

On Mon, 12 Aug 2002, Thomas Vander Stichele wrote:

> > Would you mind, the next time you go into this code, documenting your
> > changes a little more fully? I'm just wondering because I mucked about
> > in here a lot a while back, and thought I had got out all the bugs. A
> > report of the problem would be nice.
> 
> Yeah, I was going to bring this up but I got tired yesterday because what 
> I thought were simple fixes took too long to get right ;) it's still 
> tricky stuff.

Thanks for the report, it was useful :)

> Now, I put in a few fixes over the last day to do that :
> a) if it can't find the default scheduler name when it wants it, that's 
> probably a big problem.  So I put an assert in the logical place instead 
> of where it did error out.  It could be better, but it's better than 
> before.

This has been needed for a long time...

> b) if it cannot find either one of the registries when loading up an app, 
> that's a problem if you asked to work with a registry.  In that case, the 
> app will just stop running and tell you to run gst-register.  A lot saner 
> IMO until we come up with a good way of handling this stuff.

I liked the previous behavior, where it would attempt to create the user
registry. That was the idea, anyway, but...

> d) one of the main causes of irritation was when you install gstreamer so 
> that the system reg is not writable by the user you run apps as.
> So :
> - no system reg
> - system reg location not writable
> - no user reg
> The problem here was that it didn't find the system reg, tried to rebuild 
> it, then gave an assert failure because the system reg wasn't writable.
> Then it tries to write the user reg, but the paths added to that are empty 
> (they were added to the system reg).  SO the user reg doesn't find any 
> plug-ins and turns up empty.

Hm, that's super-irritating.

> What I did there was to "spill over" the paths from any registry that 
> fails to load correctly, so that the next priority registry can try to 
> register them.

Sounds great.

> It works 100% perfectly - I tried it, couldn't write the system reg, did 
> write a full user reg, and I was able to run apps, yay !

Yay :)

> My personal opinion is that we should FULLY SPEC OUT the behaviour we want 
> from registries.

Agreed. These policy decisions are difficult, what we have was just
implemented so it would work well for the case I normally use. Let's see
how to work this out, yo.

> Points to be addressed :
> 
> - warn the user when no registry is usable

Hm, I don't know about this. The user should be notified when rebuilding
the reg, but it's not really a warning. This goes together with the next
point --

> - should the registry automatically try to rebuild itself ?

I think so. I mean, it can do this; why force the user to run
gst-register when it's not really necessary? Especially for the user reg
case. MHO is that the user should just be able to run any gstreamer app
and not have to even know about the existence of the registry.

> - how does the user specify an alternate registry to read from or write to?

--gst-registry= -- it's already implemented. or GST_REGISTRY=, that's
implemented too.

> - what happens when the registry isn't writable ? path spillage ?

Path spillage, certainly. If neither the user nor the system reg is
writable, that's a big problem that should cause a warning or error or
something, like you said in your first point.

> - how do we resolve conflicting registries (my point of view: let the user
>   one take precedence)

Certainly, doesn't the user reg have higher priority now over the system
one? You saw that registries have priorities, right?

> Thoughts ?

We need to make a dia flowchart, methinks ;)

cheers,

wingo.