[Standards] Simple Jingle example(s) and spec(s) wanted

Rachel Blackman rcb at ceruleanstudios.com
Tue Feb 6 08:45:16 UTC 2007


> Personally, I don't mind implementing both specs in a client. If the
> step from a protocol for voice (which we need as well) to a protocol
> for file transfer is minimal, and if the file transfer protocol makes
> it easier to implement the voice signaling and firewall traversal (and
> even voice) step-wise, then why not use it? A client just starting up
> would only have to implement one protocol, and have it extended to
> have capabilities like voice, video, ... It would already clean up a
> few XEPs from the 'long' XEP list.

Like I said, I don't necessarily think Jingle-FT is the *wrong*  
approach.  I just think it needs to be handled properly, or else  
we'll (yet again) end up with clients that cannot all send files to  
each other.  From a technical standpoint, having a nifty new  
streaming protocol that does firewall-traversal UDP streaming may be  
great; I'm not disputing that.  But your average end-user isn't going  
to care about that: they're just going to see that Client A cannot  
send files to Client B, and vice versa, and will go back to AIM or MSN.

So, to rephrase, I'm not trying to argue that one is the 'right' or  
'wrong' way.  Just that I think plunging on and replacing a pretty  
fundamental element of the XMPP client specification with an  
incompatible one is something which should be handled with care and  
forethought.  Jabber/XMPP is still growing, definitely, but changing / 
major/ underlying definitions is something that /will/ break existing  
behaviors.  And it may drive people away to the closed systems again.

(Yes, I know Jabber's main adoption is in the corporate world, but  
corporate Jabber servers tend to be entirely behind the same firewall  
anyway, so firewall traversal is not a problem in huge problem in  
(most) corporate Jabber file transfer.)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/




More information about the Standards mailing list