On 1/24/10 5:43 AM, Jonathan Dickinson wrote: > You can 'multiplex' multiple resources into one stream. Not sure > about server support though.
On 2010-01-24, 20:55 -0700, Peter Saint-Andre wrote: > we removed the protocol for multiple resources over a single stream > from draft-ietf-xmpp-3920bis because list consensus led me to think > that people believe it is unnecessary and too complicated. On 2010-01-25, 14:40 -0700, Peter Saint-Andre wote: > The multi-resource stuff seemed like a good idea at the time but > people on the XMPP WG discussion list were concerned about adding > complexity. We could, of course, still define it as an XMPP > extension if there's interest. On 1/30/10 9:22 AM, Tomasz Sterna wrote: > One may always establish multiple connections to bring up more > resources. But I think resource binding is way simpler method. On Thu Feb 11 22:12:12 CST 2010 Justin Karneges wrote: > Also, the feature seemed to come out of left field. Maybe I missed > the discussion, but to me it felt like this feature was just a case > of "Why Not?" rather than being born from real necessity. That > doesn't make it a bad thing, but I want to remind that we should be > conservative about our changes to the core specs. Hello, The ability to multiplex multiple resources is certainly desirable. It is too bad that it has missed the core spec at this point. Strange however, that draft-ietf-xmpp-3920bis-04 still contains the text in section 1.1 Overview: "Defined of optional support for multiple resources over the same connection" Yet no where in that draft revision does it discuss multiple resources anymore. The last draft I could locate this in is: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-10.html#bind-multi Anyway, my use case for this is generalized as such, and is not IM related: An internet connected client exists for [email protected], this client is the interface to many non internet enabled clients which are identified by resources [email protected]/x1,x2..xn, where n could be a fairly large number. As x1..xn are all associated in a particular way for this use case, it makes sense (for reasons not here explained) that they are connected using a single bare JID, besides the fact that maintaining many streams/connections is certainly not ideal and even problematic. It'd be great to see this put back in the draft-ietf-xmpp-3920bis. :) I imagine that as XMPP moves further passed the IM world, these types of needs will become more apparent. It is unfortunate a forward looking update to the protocol was axed for the lack of understanding its use cases. chris _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469226/direct/01/ _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
