[Telepathy] Spec for file-transfer and tubes
Mads Chr. Olesen
shiyee at shiyee.dk
Wed Mar 14 14:40:55 PDT 2007
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:
- OfferTube, with an additional suppress_handler parameter
- Add state Tube_State_Handled for when an application has begun to use
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
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>
More information about the Telepathy