[Bug 667352] [0.11] misc core API/bug comments/nitpicks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=667352
  GStreamer | gstreamer (core) | 0.11.x

--- Comment #15 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-04-16 16:26:36 UTC ---
(In reply to comment #13)
> This is intentional, the sticky events all return TRUE when they could be
> stored on a srcpad. The reason is that a boolean value is not enough
> information to decide what goes on. It eventually works out because the
> dataflow will error out after a while (If there is dataflow, see below). 
>
> We're now in a situation where the result of pushing an event is not useful
> anymore. If you get FALSE, you know something is definitely wrong, if you get
> TRUE, you don't know, the event could be stored on a non-linked pad and will be
> pushed later.

FWIW, this actually sort-of sounds pretty ominous; "push an event, and you have
no definite idea what happened or what will happen or fail some time later"
[it also implies that any sticky event handling ---other than CAPS--- that
dares to return FALSE will likely incur quite some wrath].

IIRC at some point it was planned to have event handling also use a
GstFlowReturn so as to know more about what goes on.  In particular, it could
be used here to only discard a _NOT_LINKED but still report "real errors
upstream", but it seems that somehow got dropped along the way.

Not having such feedback means that performing a SEEKING query at one time is
all there is to know (hope?) that sending a BYTE segment downstream some other
time will probably work out ok (which all feels a bit
wobbly/contrived/unrelated).

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