[Telepathy] Spec for file-transfer and tubes

[Dafydd Harries]

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

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

 - The Ready method should be removed from
   TubeNegotiation/FileTransferNegotiation. Clients must be able to recover
   state.

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.

-- 
Dafydd