[Telepathy] The XMPP implementation of Tubes

[Dafydd Harries]

Ar 13/08/2007 am 18:20, ysgrifennodd Simon McVittie:
> On Mon, 13 Aug 2007 at 17:49:46 +0100, Simon McVittie wrote:
> > To offer a tube, send a Stream Initiation request with profile
> > NS_SI_TUBES or NS_SI_TUBES_OLD (currently, the latter is sent).
> 
> Clearly wrong, we should use the correct namespace.

This was just to allow for a transition period from the old to the new. I
think it's reasonable to require a version of Gabble that recognises the new
one now.

> > It's somewhat vague whether we support opening a 1-1 tubes channel with
> > a MUC contact - there is code to support it, but I don't think we put
> > capabilities in MUC presence. We should probably rule that it's
> > unsupported.
> 
> What I said.

Our support for presence in MUCs is somewhat shaky anyhow. I think this would
be nice to support, and I don't think it would be a lot of work, but I don't
think it's a priority.

> > In the case of D-Bus tubes, each <message> contains (a) an entire
> > D-Bus message, and (b) no more than one D-Bus message.
> 
> In 1-1 tubes we should support arbitrary fragmentation - it's relatively
> simple to parse enough of a D-Bus message to be able to find message
> boundaries.

Why are 1-1 tubes special in terms of fragmentation? It seems to me that the
same defragmentation algorighm would also apply for MUCs.

Can we simplify things by guaranteeing:

 - D-Bus message boundaries align with <message> boundaries
 - a <message> that contains the beginning of a D-Bus will always contain at
   least 8 bytes

> > The messages are sent in <message>s as specified by IBB (XEP-0047_), except
> > that the sequence number @seq is meaningless on output, must be ignored
> > on input, and no <open> or <close> ever occurs.
> 
> I propose sending <message><data xmlns=NS_TUBES>base64</data></message>.
> The data element should also have an optional attribute "frag" or
> something, with values "first", "middle", "last"; omitting the attribute
> means it's a complete message (i.e. simultaneously first and last).
> 
> This means the stream-id is meaningless and can be omitted...

I don't see the connection between the fragmentation and the stream ID.

> > :Children:
> >     parameters
> >         Tube parameters. Children are named "parameter" and have attributes
> >         "name" (user-specified) and "type" ("str", "bytes", "int" or "uint").
> >         Character content is UTF-8 (str), Base64 (bytes), ASCII decimal
> >         (int, uint).
> 
> This should be extended to support (at least) the complete set of D-Bus
> basic (non-container) types, plus 'ay'. Also, we should either explicitly
> not support the two 16-bit integer types, or note in the spec that
> 16-bit integers might become 32-bit integers in transit (dbus-glib
> doesn't let you distinguish, which is IMO a bug but we're stuck with it).

Not convinced this is useful. If we do this, do this later.

> I wonder whether it should just have Base64 character content which is
> the D-Bus serialization of the a{sv}. This can be done easily if we can
> require D-Bus 1.1.0 (i.e. dbus_message_marshal), by serializing a dummy
> message with the a{sv} as payload, then Base64ing just the body part.

I propose we keep the current scheme.

-- 
Dafydd