[Telepathy] Spec for file-transfer and tubes
dafydd.harries at collabora.co.uk
Fri Mar 9 09:40:27 PST 2007
Ar 07/03/2007 am 23:19, ysgrifennodd Mads Chr. Olesen:
> Hi all!
> Following the discussion at #telepathy this evening, I have updated
> smcv's spec proposal a little, to more or less follow the thoughts in
> the wiki at http://telepathy.freedesktop.org/wiki/Tubes .
> My darcs branch is at http://www.cs.aau.dk/~mchro/telepathy-spec.tubes/
Wow, thanks for drawing this up.
I've put it into Merge Monkey for easy review:
- StatusChanged says that the new state can be one of
LocalPending/RemotePending/Open. In practice, the tube will always begin
its life in either LocalPending/RemotePending, and will either get approved
or rejected, so in practice you'll only see StatusChanged(Open).
The events we really need to represent are Accepted, Rejected, Opened and
- The scheme for approving IP connections using the bus is cunning, but I'm
not sure if it's practical. If you're pointing your VNC client at a TCP
socket provided by the connection manager, how do you know which port it's
going to connect from?
- 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.
- In the tube type enum, I think we're better off saying "D-Bus" rather than
- Rather than giving tubes an "application name", wouldn't it be better to
give them a "protocol" or an "interface" or just a "type"? The name of the
implementation is not really what matters.
More comments as I think of them.
Discussing this in the office, we've realised we're not really clear about how
multi-user tubes should work. The OLPC folk have told us they'd like to have
it, but we don't really understand how it would be used, so we'll discuss it
with them and see what falls out.
More information about the Telepathy