[Telepathy] Spec for file-transfer and tubes

[Dafydd Harries]

Ar 15/03/2007 am 18:47, ysgrifennodd Dafydd Harries:
> Ar 07/03/2007 am 23:19, ysgrifennodd Mads Chr. Olesen:
>  - 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.

I've been discussing this with Rob and Simon, and we got a bit bogged down in
various questions:

 - should we offer a private bus for data transfer?
 - how should authentication work for local sockets?
 - is IOStream suitably general for file transfers and tubes?
 - do we really need local UDP/TCP connections, or are local Unix sockets
   sufficient?
 - how will this work if the connection manager is not on the same machine as
   the client?
 - etc. etc.

We need to get tubes working quite urgently, so we decided to adopt some major
simplifactions based on the following observations:

 - we don't need to specify tubes and file transfers simultanously
 - the only kind of tube we definitely need right now are D-Tubes, as
   stream/datagram tubes don't have useful/obvious multi-user semantics
 - we don't need data transfer over the bus right now
 - OLPC may need stream/datagram tubes, but we need to talk with them further
   to be sure

Simon also reminded us of some proposals he made in private email a while ago,
which contain some nice ideas about specifying the protocols used on top of
tubes.

With these things in mind, I'll draw up a spec patch, based on yours, that
omits file transfers and non-D-Bus tubes, and includes ideas from Simon's
proposals. We're confident that we can specify file transfers and additional
tube types in separate changes to the spec.

Because our first priority for OLPC is MUC tubes, our initial tube implementation needs to use IBB (XEP 47) rather than S5B. Given that, I propose:

 - we standardise API for tubes/file transfer separately
 - Guillaume work on implementing tubes using IBB
 - you work on implementing file transfer using S5B

Beyond that, we can look into backing tubes onto other mechanisms such as S5B,
at which point I hope some way of sharing code between tubes and file
transfers will become obvious. I think it's too early to try and anticipate
how to do that now.

Apologies if this is disruptive, but my priorities right now are, in order:

 - have a finalised tubes API
 - get MUC tubes working with Jabber IBB for OLPC ASAP
 - reuse as much of your AppConnect code as possible
 - share code between tubes and file transfers

Given that, I hope you'll agree that this approach makes sense.

Regards,

-- 
Dafydd