[Telepathy] Spec for file-transfer and tubes

[Dafydd Harries]

Ar 14/03/2007 am 22:40, ysgrifennodd Mads Chr. Olesen:
> On man, 2007-03-12 at 15:19 +0000, Dafydd Harries wrote:
> > Ar 11/03/2007 am 22:43, ysgrifennodd Mads Chr. Olesen:
> > > On fre, 2007-03-09 at 17:40 +0000, Dafydd Harries wrote:
> > > >  - I'm not keen on the Ready() method, as only one client can call it. I'd
> > > >    prefer a ListTubes method so that any client can recover the state of the
> > > >    channel. This allows different clients to decide whether they want to
> > > >    handle an incoming tube.
> > > I'm not sure that the state of a Tube is generally recoverable. A Tube
> > > can definitely not be shared between two different clients.
> > > 
> > > I was thinking of doing one client = one TubeNegotiation = many tubes.
> > > Your proposal implies many clients = one TubeNegotiation pr. contact =
> > > many tubes.
> > 
> > What about the role of Mission Control in handling tubes? When a tube
> > negotiation channel appears, which application should it launch? It can't
> > really make a useful decision until it knows what kind of tube is being
> > offered, and if this application gets started by Mission Control, it's going
> > to need to be able to recober the state of the tube.
> 
> This would give something like:
> TubeNegotiation:
> - ListTubes
> - OfferTube, with an additional suppress_handler parameter
> - RemoteTubeOffered
> 
> Tube:
> - Add state Tube_State_Handled for when an application has begun to use
> the tube.
> 
> MC would need to listen for new TubeNegotiation channels, and connect to
> the RemoteTubeOffered signal, then check the ListTubes. When MC gets a
> RemoteTubeOffered signal, with suppress_handler=false, it should handle
> it.

It seems to me you're using RemoteTubeOffered to also mean "remote end
accepted local tube", which seems like bad naming to me.

I hadn't really anticipated a case where a local client offers a tube but a
different application handles it in the case that it's accepted by the remote
end. If we can't find a concrete use case for that, I propose we don't have a
suppress_handler.

In your proposal, which client handles the case where the remote end
declines the tube?

This offer/accept/decline model makes me think we should be using the groups
interface.

> The only problem is what MC should do if the TubeNegotiation channel is
> set up, and fires the RemoteTubeOffered signal before MC is subscribed:
> How will MC find out if a handler has been launched?
> 
> How is this done for ordinary channels/connections? Is MC just racing to
> subscribe to the Connection.NewChannel signal?

There is no race. As a matter of principle in the Telepathy API design, state
is recoverable when signals are potentially missed. MC has to call
ListChannels on a connection after it becomes aware of it, to make up for any
NewChannel signals it missed.

-- 
Dafydd