[Telepathy] Simplifying the requestotron

[Robert McQueen]

Hi Simon,

Simon McVittie wrote:
> I started prototyping the Requests API in Gabble, and quickly came to
> the conclusion that requesting multiple channels, atomically, is hard -
> the distribution of channel requests across channel factories conflicts
> rather badly with the desire to make the request have no side-effects if
> it cannot be satisfied completely.
> 
> The only way I could see to do that was:
> 
> * first ask all the channel factories "hypothetically, if I asked you to
>   make these channels, which of them would you be able to make?"
> 
> * then, if there exist channel factories that claim to be able to make
>   all the channels, iterate through them and actually make the channels
> 
> This looks like failure, to be honest.

I concur.

> My new(est) proposal for the Requests interface is:
> 
> * method CreateChannel (a{sv}: Requested_Properties) ->
>   o: Channel, a{sv}: Properties

*ahem* Nice naming... :P

> * signal NewChannels (a(oa{sv}))
> 
> * signal ChannelClosed (o)
> 
> * property Channels (a(oa{sv}))
> 
> Notes:
> 
> The channel dispatcher still has to know how to dispatch multiple
> channels at once. This is unavoidable, for the "dispatch AbiWord+Text to
> AbiWord rather than sending the Text to Empathy" use case.

Right.

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

> My previous proposal had ChannelsClosed (ao), but I don't see why we would
> ever want to distinguish between channels closing separately and
> channels closing simultaneously, and ChannelClosed (o) is easier to
> implement.

No problem.

> There is no way to request multiple channels simultaneously. My
> instinct is to say that we aren't going to need it. If we do need it
> later, that's the time to add CreateChannels().

I think this is sound. I can't think of a protocol which is flexible
enough to represent bundles on the wire (XMPP with thread IDs, SIP with
session IDs, etc) but isn't flexible enough to add channels to the same
bundle later. So, any CM which is able to actually implement bundles,
will also be able to add channels to bundles later on.

> On reflection, I think that having Requested=TRUE on channels that
> appear as side-effects of a request (Text channel corresponding to
> MUC D-Bus tubes) is a mistake. We should pass the side-effects to
> approvers.

Right. Intuitively, you actually want them to go to the handler of the
original channel request, but of course it might not actually be a
handler for that channel type. So, heading through the normal dispatch
procedure is unavoidable I think.

> If closing the side-effect channel automatically closes the desired
> channel (leaving the MUC closes the tubes), this is bad. The solution
> that Sjoerd and I settled on was:
> 
> * If the Text channel is closed while there are Tubes open in the same
>   chatroom, the Text channel "respawns" as per
>   http://monkey.collabora.co.uk/tp-spec-smcv-text-respawn

+1

> * The Tube channels have a "Requires" property pointing to the Text
>   channel, to indicate this relationship to the channel dispatcher

+1

> * Ideally, the channel dispatcher passes a hint to approvers
>   (RequiredBy?), to indicate that "reject" is not a useful action for
>   Text channels that are required by Tube channels - otherwise, the user
>   could click "reject" but the channel would pop back up again! "Handle"
>   and "ignore" are the only useful actions for such channels.

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.

> Thoughts? Particularly from Rob, but any ideas welcome!

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?

>     smcv

Regards,
Rob