Menu
▾
▴
pidgin-devel
|
From: Evan S. <ev...@ad...> - 2007-03-29 23:58:19
Attachments:
PGP.sig
|
I'd like to start a cross-list Adium/Gaim dialogue about the future of Bonjour, especially as it relates to XMPP. Apparently, the Bonjour protocol as implemented by iChat is a small subset of XMPP but there's no reason not to fully support everything XMPP has to offer. That includes, of course, eventual Talk support via libjingle, just-as-a-for-instance. The only part of XMPP which is excluded when using Bonjour is the roster, it appears. We discussed this a bit on adium-dev already. Adium currently utilizes libezv, a BSD licensed implementation of Bonjour which is approximately where the libgaim bonjour prpl is at present (presence, messaging, typing status) with what I believe are a few extras (buddy icon support) but some similar limitations (no file transfer, for example). One thing libezv *does* get us in Adium is the use of OS X's systemwide mDNS stack via native calls. Really, as I understand it, Bonjour is XMPP but with (1) different network code, which routes through an mDNS stack instead of traditional network calls and (2) different presence handling, especially since there is no Bonjour Roster. What if the Jabber prpl were split, similarly to how Oscar was split into AIM and ICQ, but with a significantly greater degree of split complexity? Jabber and Bonjour wouldn't be treated as the same protocol in terms of what a user (or a UI) saw, but at the heart they could share the vast majority of their code. Bonjour would do network activity via GaimBonjourMDNSCallback functions, or the like, such that the UI would be able to use the best available library. In the case of Gaim, that would be Howl initially but hopefully Avahi in the future. In the case of Adium, this would be the appropriate DNSServiceDiscovery and CoreFoundation framework calls. We have a couple strong Google Summer of Code proposals related to Bonjour that we're considering for Adium, and I see a number of proposals related to it in the Gaim GSoC applications list, as well. A project in this direction could have big payoff, especially looking forward: we would bring a mature, capable, growing XMPP implementation to Bonjour, raising the bar as to what a Bonjour client can and should do. The time to think about this and discuss it is now, while we have interested students looking to get involved in an important project and before we allow them to work in a direction which might soon be reversed. Thoughts? Please reply-to-all; my apologies for the extra traffic to those of you who are subscribers of both lists. -Evan |
|
From: Evan S. <ev...@ad...> - 2007-03-30 01:20:44
Attachments:
PGP.sig
|
On Mar 29, 2007, at 9:14 PM, Richard Laager wrote: > Is there any effort to standardize XMPP over mDNS? Would it be > compatible with Bounjour? I should have included this bit of information in my original post: Bonjour is now defined as XEP-0174 [1] and also called "Link-Local Messaging". My entire lengthy post, then, could really be summarized as: Rather than implementing Bonjour as an entirely separate protocol, XEP-0174 should be implemented in a sub-prpl of the existing XMPP prpl. This implementation should allow the UI to use the mDNS implementation of its choice. [1] http://www.xmpp.org/extensions/xep-0174.html Cheers, Evan |
|
From: Sean E. <sea...@gm...> - 2007-03-30 02:35:59
|
On 3/29/07, Evan Schoenberg <ev...@ad...> wrote: > I'd like to start a cross-list Adium/Gaim dialogue about the future of > Really, as I understand it, Bonjour is XMPP but with (1) different network > code, which routes through an mDNS stack instead of traditional network > calls and (2) different presence handling, especially since there is no > Bonjour Roster. Mark, who wrote our initial Bonjour stuff, disagrees. He says that only the format of the messages is the same. Everything else is vastly different, and our code base seems to confirm that. Someone should try sending iChat some XMPP stanzas other than <message/> and see what happens. A good test would be to send iChat something like: <iq to='whatever' id='asdf' type='get'><foo xmlns='http://gaim.sf.net' /></iq> and see if iChat responds with an IQ error. If it doesn't, there's probably no point in trying to reuse the Jabber code. -s. |
|
From: Evan S. <ev...@ad...> - 2007-03-30 03:27:05
Attachments:
PGP.sig
|
On Mar 29, 2007, at 10:35 PM, Sean Egan wrote: > Someone should try sending iChat some XMPP stanzas other than > <message/> and see what happens. A good test would be to send iChat > something like: > > <iq to='whatever' id='asdf' type='get'><foo xmlns='http:// > gaim.sf.net' /></iq> > > and see if iChat responds with an IQ error. Well, on the one hand, iChat (version 3.1.7, which ships with OS X 10.4.8) replies: <iq id="asdf" type="error"><error type="501">Client has no handler for IQ type get namespace http://gaim.sf.net</error></iq> Interestingly (to me -- is there a perfectly good reason for this?): Send: <iq to=’10.0.1.105’ type=’get’><foo xmlns=’http://jabber.org/ protocol/disco#info’/></iq> Response: <iq type="error"><error type="501">Client has no handler for IQ type get namespace http://jabber.org/protocol/disco#info</ error></iq> But try something that I think oughta be valid: Send: xml <iq to=’10.0.1.105’ type=’get’><query xmlns=’http:// jabber.org/protocol/disco#info’/></iq> Response: 0 bytes, which libezv normally treats as "connection closed" (and perhaps properly so). What do you make of that? -Evan |
|
From: Sean E. <sea...@gm...> - 2007-03-30 03:43:42
|
On 3/29/07, Evan Schoenberg <ev...@ad...> wrote: > But try something that I think oughta be valid: > Send: xml <iq to='10.0.1.105' type='get'><query > xmlns='http://jabber.org/protocol/disco#info'/></iq> > Response: 0 bytes, which libezv normally treats as "connection closed" (and > perhaps properly so). <iq/> stanzas MUST have an id attribute. Try adding one and see what happens. -s. |
|
From: Evan S. <ev...@ad...> - 2007-03-30 04:39:58
Attachments:
PGP.sig
|
On Mar 29, 2007, at 11:43 PM, Sean Egan wrote: > On 3/29/07, Evan Schoenberg <ev...@ad...> wrote: >> But try something that I think oughta be valid: >> Send: xml <iq to='10.0.1.105' type='get'><query >> xmlns='http://jabber.org/protocol/disco#info'/></iq> >> Response: 0 bytes, which libezv normally treats as "connection >> closed" (and >> perhaps properly so). > > <iq/> stanzas MUST have an id attribute. Try adding one and see > what happens. I get the same 0-byte response with: <iq to='10.0.1.105' id='asdf' type='get'><query xmlns=’http:// gaim.sf.net’/></iq> and <iq to='10.0.1.105' id='asdf' type='get'><query xmlns=’http:// jabber.org/protocol/disco#info’/></iq> In both cases, iChat reports that the remote user (the one who sent the XML) left, then reports that it left. When sending blantantly invalid strings directly, it behaves the exact same way; for example, the following: <message to="10.0.1.105"><body>foo</body></invalid> (whereas replacing that </invalid> with </message> works just fine) -Evan |
|
From: Evan S. <ev...@ad...> - 2007-03-30 04:56:32
Attachments:
PGP.sig
|
On Mar 30, 2007, at 12:39 AM, Evan Schoenberg wrote: > I get the same 0-byte response with: > <iq to='10.0.1.105' id='asdf' type='get'><query xmlns=’http:// > gaim.sf.net’/></iq> > and > <iq to='10.0.1.105' id='asdf' type='get'><query xmlns=’http:// > jabber.org/protocol/disco#info’/></iq> > > In both cases, iChat reports that the remote user (the one who sent > the XML) left, then reports that it left. > I take it back; sorry for the confusion. I'd been copying and pasting in my continued tests.. and at some point I pasted somewhere which made smart quotes, and that made iChat angry. Carefully typing from nothing, I can elicit: Sending <iq to='10.0.1.105' id='asdf' type='get'><query xmlns='http:// jabber.org/protocol/disco#info'/></iq> Received <iq id="asdf" type="error"><error type="501">Client has no handler for IQ type get namespace http://jabber.org/protocol/ disco#info</error></iq> which is exactly what we want and expect. So it looks like we can do capabilities discovery and then do the Right thing when playing with iChat and with other, more capable clients. -Evan |
|
From: Mark D. <ma...@ki...> - 2007-03-31 19:25:41
|
On Thu, 29 Mar 2007 21:20:33 -0400, Evan Schoenberg wrote > Rather than implementing Bonjour as an entirely separate protocol, > XEP-0174 should be implemented in a sub-prpl of the existing XMPP > prpl. This implementation should allow the UI to use the mDNS > implementation of its choice. I'm ok with this as long as we can guarantee that we're always compatible with iChat. So we should never do anything that causes us to get disconnected from an iChat client, or stop showing up in their buddy list. -Mark |
|
From: Evan S. <ev...@ad...> - 2007-03-31 19:49:31
Attachments:
PGP.sig
|
On Mar 31, 2007, at 3:27 PM, Mark Doliner wrote: > I'm ok with this as long as we can guarantee that we're always > compatible with > iChat. So we should never do anything that causes us to get > disconnected from > an iChat client, or stop showing up in their buddy list. Agreed that that's a necessity. So far as I can tell in cursory testing, sending any sort of invalid XML can drive iChat crazy (chat ended, further chatting can't be initiated by iChat but can still be done if the sending-invalid-XML side initiates the conversation)... but it seems to ignore valid but nonsensical XML. -Evan |
|
From: Sean E. <sea...@gm...> - 2007-04-04 14:02:14
|
I am now totally and strongly in favor of doing this. We should totally do this: we still have a problem of abstracting the difference between different bonjour implementations, though. On 3/31/07, Evan Schoenberg <ev...@ad...> wrote: > > > On Mar 31, 2007, at 3:27 PM, Mark Doliner wrote: > > > I'm ok with this as long as we can guarantee that we're always compatible > with > > iChat. So we should never do anything that causes us to get disconnected > from > > an iChat client, or stop showing up in their buddy list. > Agreed that that's a necessity. So far as I can tell in cursory testing, > sending any sort of invalid XML can drive iChat crazy (chat ended, further > chatting can't be initiated by iChat but can still be done if the > sending-invalid-XML side initiates the conversation)... but it seems to > ignore valid but nonsensical XML. > > -Evan > _______________________________________________ > Adium-devl mailing list > Adi...@ad... > http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com > > > |
|
From: Evan S. <ev...@ad...> - 2007-03-31 20:43:12
Attachments:
PGP.sig
|
On Mar 31, 2007, at 4:35 PM, Christopher O'Brien wrote: > On Mar 31, 2007, at 3:49 PM, Evan Schoenberg wrote: >> Agreed that that's a necessity. So far as I can tell in cursory >> testing, sending any sort of invalid XML can drive iChat crazy >> (chat ended, further chatting can't be initiated by iChat but can >> still be done if the sending-invalid-XML side initiates the >> conversation)... but it seems to ignore valid but nonsensical XML. > > I think you mean "not well-formed" instead of "invalid", and > "invalid" instead of "nonsensical?" "Valid" specifically means that > it validates to a schema, and "well-formed" specifically means it > can be correctly parsed as XML. Ah, thank you - I'm not (yet) up on my XML terminology Yes, that's exactly what I mean. iChat doesn't handle not well-formed XML elegantly, but it does properly respond to well-formed invalid XML. -Evan |
Thanks for helping keep SourceForge clean.
X