> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Nicholas Perez > Sent: Tuesday, September 30, 2003 9:23 PM > To: [EMAIL PROTECTED] > Subject: Re: [JDEV] Promiscuous presence for user communities > (with patch) > > > > > Steven Brown wrote: > > >It could also be implemented as an optional namespace under > <presence>, > >e.g., the client could send <presence type="available"><promiscuous > >xmlns="..."/>...</presence> and capable servers would use it and > >incapable servers would ignore it and just treat it as a normal > >'available' presence. That wouldn't modify the protocol afaik. I > >figured it would make more sense as a type due to the way 'invisible' > >had been implemented as a type instead of making it a tag under a > >type="unavailable". Would the promiscuous tag under presence as > >mentioned be better? > > > > > Presence is already a rather large payload for its given > task. That is > alot of bandwidth for non-conforming servers.
Oh common, a couple clients sending an added "<promiscuous xmlns="..."/>" when they change state is going to kill server bandwidth? Have you looked at JEP-0080? :) > And it is changing the > protocol. Substantially. If your kind of misfeature is let go > unchecked, > it only encourages other misfeatures. It's not changing the protocol. Well, type="promiscuous" does (in a non-breaking way at least), but the change I suggested to have it live under type="available" with its own xmlns instead wouldn't. > If you want this kind > of change to > the protocol, then please take the time to write a jep and > submit it for > peer review on the Standards JIG mailing list. I'm currently just using it for my own use (custom Jabber and custom client), but I would eventually like to push it as far as it will go in terms of standardization. If 'as far as it will go' is just living as a patch that interested people can use, that's fine, too. It'll have to be after UbiComp before I have time to write a JEP, but the suggestions I'm getting now (like avoiding using the type attribute) are valuable. As-is, it's not yet intended for everyone, just folks that have a need for it in their own custom setups; e.g., folks that want to add 'online users on in the roster' support can start from this. > Simply > adding something and saying "non-conforming clients/servers can just > ignore it" takes a giant crap in our punch bowl of an organization we > have carefully built, and meticulously control. Uhh, isn't the entire point of Jabber's XML protocol (and XML in genereal) that you can add properly namespaced children to elements and they'll get ignored by folks that don't understand that namespace? Like section 9.2 of the IETF XMPP core spec? Or were you planning on having every single application written that communicates new data over Jabber to first get a stamp of approval from you? That'd be news to a lot of folks I think. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
