[Telepathy] Simplifying the requestotron

[Simon McVittie]

I'm going to try implementing my proposed simple-requestotron in Gabble,
while we discuss whether to resurrect EnsureChannel and/or plurality.

On Wed, 23 Jul 2008 at 14:05:24 -0700, Robert McQueen wrote:
> Simon McVittie wrote:
> > There is no way to say "give me an existing channel if possible, else
> > a new one". The only use-case I can see for this is ContactList
> > channels, for which the old API is sufficient. This means that before
> > deprecating RequestChannel we must either add EnsureChannel (as Rob
> > proposed last week), or replace ContactList channels with a
> > Channel.Interface.Roster - I don't know which way we're going to go on
> > this, but I don't want to block on making that decision.
> 
> I feel EnsureChannel is a reasonable API to present to do
> atomic-lookup-or-create, even if in the fullness of time the channel
> dispatcher doesn't use it.

Do ensured channels get Requested=TRUE or Requested=FALSE?

If they are Requested=FALSE I find it hard to explain why this is
conceptually valid! For contact lists we justify it as "we're just
making sure that a channel that was going to exist anyway, does"; for
contact groups it's all a bit odd.

(Note that my trial implementation of Requested in Gabble doesn't bother
tracking requestedness for contact lists/groups, it just claims they
weren't.)

If they are Requested=TRUE, I think we have to have EnsureChannel return an
indication of whether the channel was created due to *this* request or not.

Channels that are Requested=TRUE don't get approvers or handlers in
response to the NewChannels signal, so the caller of EnsureChannel would
be responsible for giving it to (or being) the handler, *if and only if* it
was created for *this* request (as opposed to any other request that may
have happened in parallel...) - IOW, the CM has to pick one of the requesters
(the one calling CreateChannel, if there is one, else an arbitrary caller
of EnsureChannel) and declares that it's the responsible one.

Of course, for the current intended usage (ContactList channels) it doesn't
matter, because we're proposing that all ContactList users should be
observers... but if this is a generic API, rather than something we're
gashing on for the benefit of contact lists, then we should define what
it means.

> Sounds reasonable too. I think the dispatcher should endeavour to send
> the required channels to the handler of the channel that requires it, in
> the same vein as handling channels belonging to existing bundles.
> 
> Saying that, I'm kind of wondering if this doesn't actually point to
> something else we scrawled on the whiteboard last week.. Namely that
> these required channels should just be in the same bundle, and then
> they'll behave roughly correctly.

Yeah, they will of course be in the same bundle (if/when we merge
Bundles :-)

> My oustanding concern is (required channels aside), if you can only
> request channels separately, when you want the tube+text channel
> combination, the CM will get them separately, and presumably signal them
> separately, so the other end will emit two separate NewChannels signals
> each with one channel in. Does this just make things order-dependent,
> meaning you need to request the channel which will determine the handler
> first, or it will be misdespatched at the other end, which is exactly
> the thing bundles and multi-requesting was intended to avoid?

I believe it just makes it order-dependent. Conceptual rule which works
for the particular case of Tubes + Text in MUC: you should request the
"most characteristic" channel first.

The only way "atomic" channel requests can ever work, in any case, is if
they're really part of the same protocol feature - Gabble already uses
the same channel factory for MUC-tubes and MUC-text.

Perhaps it would be sufficient to remove the "no side-effects unless all
can succeed" constraint, and have CreateChannels always "succeed"? For
each channel, it would either return a channel, or the D-Bus error that
CreateChannel would have thrown.

Evil suggestion of evil: if we want the concept of a simultaneous
requesty thing, we can later invent a Channel.Type.Plural that just
wraps the real channels...

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20080724/2025dbb6/attachment.pgp