[Bug 24768] need CD API to list existing channels you might like to Observe

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24768


Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://git.collabora.co.uk/?
                   |                            |p=user/ptlo/tp-spec-
                   |                            |senko/.git;a=shortlog;h=refs
                   |                            |/heads/respawnable-observers
  Status Whiteboard|                            |review-, minor changes




--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-03-25 07:17:54 PST ---
>        <p>When the ObserveChannels method is called due to observer recovery,
>        the "Observer_Info" dictionary will contain one extra item with key
>        "ExistingChannel" and boolean value of True.</p>

Our case convention for "extra misc info" dicts is usually like GObject
properties (so, "existing-channel" in this case).

I think this key should be called "recovering", actually.

The Observer_Info parameter to ObserveChannels should document it, too.
Pseudocode, in which /foo/ indicates a hyperlink:

    recovering : b
        If present and TRUE, this channel already existed before the observer
        started, and is being supplied to it due to the /Recover/ property
        (see that property for details).

>        <tp:rationale>
>          <p>The observers might hold state or do channel-specific initialisation
>          for the channels they observe. This is a way of signalling to them
>          that they were already observing this channel, so they don't have to
>          do extra round-trips to query for this information.</p>

I think this rationale is wrong. If you receive a channel with 'recovering',
then by definition you've just started up, so you have no state!

Instead, the rationale for the "recovering" key should be something like:

    This allows observers to distinguish between new channels (the normal
    case), and existing channels that were given to the observer in order
    to catch up on previous events (perhaps after a previous instance of
    the same observer crashed).

Do you have an implementation of this in MC? I'll clone this bug for the
implementation; please attach any implementation for review to the clone, with
the patch keyword.

This spec change can potentially be merged without an implementation in MC, but
can't be undrafted until we have a suitable implementation. To be honest, since
this branch is so small, I'd be inclined to implement it in MC based on this
draft, and not bother to merge it to the spec until we have a reasonable
implementation on a branch, at which point it can go straight in as stable API.

When this is ready for review again, please remove review- from the status
whiteboard and re-add the patch keyword.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.