[Telepathy] The XMPP implementation of Tubes

[Simon McVittie]

On Thu, 16 Aug 2007 at 11:40:54 +0200, Guillaume Desmottes wrote:
> Le lundi 13 août 2007 à 22:39 +0100, Simon McVittie a écrit :
> > I'm tempted to specify that for D-Bus tubes, the initiator makes one SI
> > request per D-Bus tube; but that for stream tubes, the initiator sends a
> > <message> containing a <tube>, and the non-initiator responds with SI
> > requests.
> > 
> 
> Indeed, maybe that would be saner that way. I my mind, a private tube
> offering always implied a SI request but maybe that was a wrong
> assumption.

Well, if you're offering a private stream tube, that means "you may make
one or more connections to me". Only the non-initiator knows how many
connections are actually wanted (consider proxying Apache via Tubes - even
with HTTP 1.1 keep-alive, the non-initiator's web browser is likely to make
multiple separate TCP connections). So, I think it's conceptually the
non-initiator that opens the streams.

This also nicely parallels the way we do MUC stream tubes, with the
offer not being an SI IQ.

The other possible approach would be for the "default bytestream" to be used
for the first connection, with the non-initiator creating additional
bytestreams for any subsequent connections. I don't like the
inconsistency there - if the initial message from the initiator is
special, it should be a different message.

> > > Responding to a tube offer is as usual for SI. Once the other end has
> > > agreed to do IBB, we consider the tube to be open.
> > 
> > Possibly we shouldn't consider the tube to be open until the IBB <open>
> > has been sent.
> > 
> 
> We do I think.

I may have been misled by the fact that gabble_bytestream_ibb_initiation
calls the callback "successfully" as soon as the other end has agreed to
do IBB, before the <open> has happened.

> > I propose to remove this attribute, and use the tube ID as an attribute
> > on the pseudo-IBBs in MUC D-Bus tubes, instead of a session ID.
> > 
> 
> Hum can't remember why this attribute was added.

Because you were trying to twist IBB into something you could use in a MUC? :-)