[Telepathy] The XMPP implementation of Tubes

[Simon McVittie]

On Wed, 15 Aug 2007 at 13:26:40 +0100, Dafydd Harries wrote:
> > > 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.

In MUC D-Bus you can get dropped into it at any time, including halfway
through a message. In SI, it's guaranteed that you're starting from the
beginning.

> Can we simplify things by guaranteeing:
> 
>  - D-Bus message boundaries align with <message> boundaries

I think this guarantee is a bit of an abuse of IBB. For MUC D-Bus, if we
switch to a separate namespace, sure.

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

This would simplify the implementation, if "8" is replaced by "16"
(the header fields array length ends there).

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

Sorry, I meant to say that the <data> would have a tube-id attribute.
*That* is what makes the stream ID redundant. Simultaneously, the fact
that we're no longer trying to fake IBB means that the stream ID isn't
"required by the DTD" (if you see what I mean).

Any thoughts on the issue of inability to send string parameters
containing non-XML control characters? (1-31 minus a few - D-Bus already
guarantees no NULs in a string, so 0 isn't a problem)

	Simon