[gstreamer-bugs] [Bug 628014] New: Deprecate GST_FLOW_IS_FATAL/GST_FLOW_IS_SUCCESS

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=628014
  GStreamer | gstreamer (core) | git

           Summary: Deprecate GST_FLOW_IS_FATAL/GST_FLOW_IS_SUCCESS
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: slomo at circular-chaos.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


As we've seen yesterday (bug #627946) GST_FLOW_IS_FATAL can easily be misused.
I'd propose to deprecate it and also deprecate GST_FLOW_IS_SUCCESS while we're
at it.

The problem with both macros is, that they suggest something that isn't true.
If GST_FLOW_IS_FATAL is true, there could still be a problem for many elements
and they should stop what they're currently doing and return that value
upstream (e.g. not-linked in a parser). If GST_FLOW_IS_SUCCESS is false, it
could still be that this is "ok" for the element (e.g. not-linked for a demuxer
on a few of its pads but not all).

It's better to not have these "convenience" macros but instead let people
*think* about the handling of different flow returns, that makes sense for
their element. And we should document the expected handling of flow returns for
different classes of elements in the plugin writer's guide.

Patch to deprecate the macros comes later

-- 
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.