[Bug 794153] New: GstPromise is weird

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 794153
           Summary: GstPromise is weird
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: jan.steffens at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I'm familiar with Promises (JavaScript async), Futures (Python concurrent and
asyncio) and GTask. An unordered list of gripes with GstPromise:

- It has no concept of failure.
- Nullable GstStructure seems to be a bad fit for a reply.
  - Forced into the schema of a name + string-GValue-map.
  - Overkill for returning a simple value.
  - No obvious way of signaling an error.
- No means of signaling the promiser from the promisee.
  - No cancellation of operations other than the promiser polling the promise
for result changes.
- The purpose of INTERRUPTED and EXPIRED is not clear.
  - INTERRUPTED results in a reply succeeding but the structure is freed.
  - EXPIRED results in criticals on any manipulation, but nothing using
GstPromise sets or checks for expiration.
  - Was INTERRUPTED or EXPIRED meant for cancellation?
- The promisee creating the Promise and passing it to the promiser is weird.
  - I am used to seeing the promiser returning a promise.


Some suggestions:

- Split the promise into two objects created together, one for the promiser
(GstPromise?) and one for the promisee (GstFuture?).
  - Both sides have a change notification callback.
  - Setting a callback on a non-PENDING side immediately fires the callback.
  - The promisee side can be cancelled, then both sides become
INTERRUPTED/CANCELLED.
  - If any side is freed while PENDING, the other side is EXPIRED.
    - EXPIRED cannot be set any other way.
    - EXPIRED on the promisee side results in a noisy warning. Promisers
shouldn't forget about their promises!
  - Trying to reply to an EXPIRED or INTERRUPTED promise succeeds but does
nothing.
  - Interruption is a signal to the promiser to abort, expiration is not
necessarily one.
- Split REPLIED into RESOLVED/FULFILLED/SUCCESS/OK and REJECTED/FAILURE/ERROR.
  - Success and failure come with a GValue.
- Have the promiser create the objects and return the promise.
- Have some additional constructors to shortcut creating a promise that's
already resolved or already rejected.
- Have some helper functions to shortcut fulfilling with common types or
rejecting with a GError.

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