[Psi-devel] coccinella bytestreams

[Justin Karneges]

On Wednesday 16 May 2007 8:03 am, Hal Rottenberg wrote:
> interesting and relevant post: http://coccinella.im/node/45

Cool.  I commented, but it looks like he's got comments not showing.  Here was 
the text, in case anyone wanted to read it:

-----
Hi,

I was referred to your post here, and I just wanted to comment on a few 
things:

1) Connecting to the streamhosts in order (that is, waiting for failure before 
moving to the next one.. the XEP isn't clear on that) can result in very slow 
negotiations. Gaim, for example, is known to get stuck for many minutes if 
the first streamhost cannot be reached. A trickle-connect (like ICE) might 
make more sense than waiting for full failure, but again the XEP doesn't go 
into that kind of depth about what it means to connect in order.

2) Psi tries to prioritize the streamhosts by use of the <proxy> element. 
Basically all non-proxy streamhosts are tried first until failure, and then 
the proxy streamhosts are tried.

3) Fast mode is complex, but anything like this will be complex. Maybe it 
would have been slightly simpler to not use the extra CR character for 
activation, but the result would still be very complex. You should have seen 
the things the council used to reject: fallback from S5B to IBB in XEP-95/96 
for example (where Jive has proposed their own extension), and also the 
original reverse connection text in XEP-65 (which was like fast mode, except 
not simultaneous. initiator did a full s5b negotiation, and if that fully 
failed, the target would initiate s5b in the other direction.. how is this 
complex?!). Fortunately, the council is different now and more accepting of 
complex protocols (see Jingle, which would have been rejected instantly in 
the old days).

Anyway, great to see another fast mode implementation!

-Justin