[Telepathy] Simplifying the requestotron

[Simon McVittie]

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.

My new(est) proposal for the Requests interface is:

* method CreateChannel (a{sv}: Requested_Properties) ->
  o: Channel, a{sv}: Properties

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

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.

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.

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

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.

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

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

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

Thoughts? Particularly from Rob, but any ideas welcome!

    smcv
-------------- 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/20080723/1ced0e5c/attachment.pgp