Re: [gst-devel] error handling in gstreamer

[Ronald B. <rb...@ro...>]

Hey Thomas & all,

On Sat, 2003-05-31 at 15:56, Thomas Vander Stichele wrote:
> While testing this, it pointed out a very obvious problem.  I selected
> "chart" from the menu of vis stuff, set to play, and got the error
> "could not negotiate format".
> 
> Now, if a user sees that, I don't really know what he is supposed to do
> :)

In this particular example, my opinion is that it's a developer error.
The pipeline should contain audioconvert. However, that isn't in 0.6.x,
so we'd need to backport it.

However, the general point still stands.

> What the error message SHOULD say is something like "vorbisfile: could
> not connect stereo to mono between vorbisfile and chart", or something
> to that effect.  That would be a useful error message because it can be
> reported back to us for fixing.

The thing is that if you want to do this, you require information from
different levels, which we currently don't do. And although I'm in
favour of using GError, it won't help to create such messages. At best,
we'll have the core saying that it couldn't connect vorbisfile.src to
chart.sink and chart saying that we couldn't agree on caps (with
possibly a hint that it only accepts mono audio). Vorbisfile doesn't
know it's linking to chart, chart doesn't know it's linking to
vorbisfile, and in a somewhat more general case where the template caps
are already fixed, chart doesn't even know why negotiation failed
because gst_caps_intersect() returns nothing, so caps negotiation never
actually starts. Vorbisfile doesn't know this (and it shouldn't).

> Now, what I want to ask/discuss is, how can we make this happen ? It
> needs changes on a few levels.
> 
> The error message itself is generated in vorbisfile.
> gst_vorbisfile_new_link is called when a new link is being set up.  It
> calls gst_pad_try_set_caps, and then it returns FALSE when that fails.
> The calling function (gst_vorbisfile_loop) then prints this very obtuse
> error message because of that.

(gst_pad_try_set_caps() returns a GstPadLinkReturn.)

> Now, the question is, how do we get the relevant data out of the core to
> the UI ?

I think the relevant question is whether the UI needs to know all these
details of why caps negotiation failed. I don't think so. Putting it in
a GST_DEBUG() macro seems good enough to me, and we'll ask the user for
a --gst-mask=0x1000000 (where 1000000 means GST_CAT_NEGOTIATION, it's
probably a different number but that's besides the point) to see
details. The UI only wants relevant information, such as "could not set
up chart" or so, and give the option to move on to synaestasia or so. A
user doesn't care about links, PadLinkReturns, failures, reasons of
failures (unless it's a user error), etc - neither should the UI (in
error reporting). It just cares about *whether* it failed.

> gst_pad_try_set_caps doesn't offer any clue on why it failed.  It should
> somehow be able to tell us that it failed because it can't link stereo
> to mono.  One possible way of doing this is have a new function (e.g.
> gst_pad_try_set_caps_error (pad, caps, error)), where error offers some
> indication of what went wrong (what error is exactly is to be
> discussed).

Well, the point is that the capsnego callback per plugin also needs a
GError then, and that's ABI/API breakage. Unless you make it optional,
but that'll be a *huge* messup of our internal API, I'm not really in
favour of that. You could add an extra function to the core only and let
the core fill in the error. That'll be more generic, but at least we
wouldn't completely mess up our API. And since the user doesn't need to
know all those details, I don't actually think this question is
relevant.

> Now, as for the format of this error, I think we have three possible
> choices:
> a) define a bunch of enums for GST_ERROR's, a la GST_ERROR_CAPS_FORMAT
> in this case
> b) create a GstError that is very gst-specific
> c) use GError

(If we wanted to go for this anyway, even though I just said we don't
need to: GError, definately. It was made for this. A second option to
consider is to make more detailed use of gst_element_error(), with more
detailed and explanatory error messages... I actually think that's a
good idea.)

> The question then is, how do we handle i18n.  I see a few possible ways
> of doing this :
> 
> a) gettextize plugins (and possibly core), keep .po files in our cvs
> b) gettextize, put .po files in gnome cvs and sync them back regularly
> c) don't gettextize, but provide helper functions to help an app i18nize
> their own messages based on our english messages
> d) gettextize, move to gnome cvs
> 
> I'm not sure what the best option is at this point (leaning towards b)
> though), but we need to discuss it.

I don't really like (b), it looks like a lot of work (the back-and-forth
syncing) that we will often neglect. (d) sounds ok, though it'll mean a
string freeze once in a while. Given that gst_element_error() messages
will appear in the UI, we'll need to i18'ize these.

On the other hand, the Gnome CVS doesn't use SSH for encryption, so I
don't really like that idea. SF isn't perfect, but I'd rather stay on
SF. And now that KDE is looking around the corner, this wouldn't be a
politically correct idea.

In conclusiam: I don't know. ;).

Ronald

-- 
Ronald Bultje <rb...@ro...>