[Telepathy] Spec for file-transfer and tubes
dafydd.harries at collabora.co.uk
Thu Mar 15 11:47:16 PDT 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/
> Basically, there is 2 new channel types: FileTransferNegotiation and
> TubeNegotiation to offer and get offered tubes and files.
> 4 new non-channel types:
> - IOStream for pumping raw data forth and back
> - FileTransfer for receiving a file - uses IOStream
> - Tube for handling a raw data tube (e.g. a TCP-connection or UDP) -
> uses IOStream
> - DTube for handling a D-Bus connection - doesn't use IOStream
For me, the main things I'd like to see changed are:
- I don't think there should be a Tube object. All negotiation should happen
inside the TubeNegotiation channel, including
offering/accepting/declining/closing a tube. The TubeStateChanged signal
should be on the TubeNegotiation interface. Tubes should be identiied with
unique IDs. Rationale: this reduces the number of objects you need to deal
with from 3/2 to 2/1 (depending on whether you do your data transfer over
the bus or using a local socket).
- Likewise, I think the TubeFileTransfer object is an unnecessary
- In general we shouldn't conflate file transfers and tubes in the API. They
may use the same underlying mechanism at the protocol level, but many
protocols have native support for file transfer whereas tubes are always a
Telepathy-specific extension. This aside, I think the IOStream interface is
probably general enough to be used for both tubes and file transfers, even
if it is a little bit weird that IOStreams used for file transfer will
always end up being read-only or write-only.
- For now, we should forbid multi-user stream/datagram tubes as they don't
have clear semantics when data is transmitted over a local socket. Later we
may devise a protocol where datagrams are prefixed with the sender handle,
but we should defer addressing this need if it occurs rather than trying
to anticipate a need for it now. This means that the only kind of tube you
can request on a multi-user channel is a D-Tube. The CM must raise
NotImplemented (NotAvailable?) if you try to request a different type of
- The Ready method should be removed from
TubeNegotiation/FileTransferNegotiation. Clients must be able to recover
I think if we make these changes, the interface is more or less ready to merge
from my PoV, barring any issues I haven't noticed.
More information about the Telepathy