[Telepathy] Spec for file-transfer and tubes

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

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?

-- 
Mads Chr. Olesen <shiyee at shiyee.dk>
shiyee.dk