<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> That's a good point about dealing with non-XEP-0033 clients. But from my point-of-view I'm only concerned with getting a solution - if that means requiring users here to use only pidgin (or whatever client) to get full benefit, that's ok. Graceful interaction with non-XEP-0033 clients, while desirable, isn't a priority, I just need to be able to say "here's a way to get the job done". I'm not familiar enough with XMPP to know exactly what's possible purely on the client side and what requires a server component, so thanks for the advice. Maybe I need to be soliciting work on the pidgin developers'  list instead... :) Thanks, Jeff McAdams wrote: <blockquote cite="mid:486A3EE4.1010906@iglou.com" type="cite"> <pre wrap="">Toby Schaffer wrote: </pre> <blockquote type="cite"> <pre wrap="">I hope nobody minds me bringing up an older thread... Responding to Nathan's original reply <a class="moz-txt-link-rfc2396E" href="http://mail.jabber.org/pipermail/jdev/2008-June/026983.html"><http://mail.jabber.org/pipermail/jdev/2008-June/026983.html></a> that this should be handled as a MUC which the client could make transparent, I'm hoping for something that requires no interaction from the user, not even having to accept a MUC invitation. </pre> </blockquote> <pre wrap=""> Again, its quite possible for a client to do this. The protocol (particularly with the <continue/> element) has the necessary bits and parts to let the client know that it should be a seamless transition...both on the initiating, and receiving side. This is all client implementation issue. </pre> <blockquote type="cite"> <pre wrap="">Ideally, the message would simply appear on the recipients' screens as if they were IM'd individually (except for the other recipients' JIDs, of course). Again, it seems that XEP-0033 addresses all this, and I'm surprised there are no implementations. </pre> </blockquote> <pre wrap=""> You are correct, though, in that you could use XEP-0033 capabilities to do this as well...though I suspect you're going to find a lot more interoperability corner cases when working with other clients that don't support XEP-0033. At least, with the MUC case, if you're interacting with a client that doesn't provide that seamless user experience, it will "gracefully" fall back to giving a MUC invite to the user to confirm. If you're interacting with a client that doesn't support XEP-0033, your multi-way flow of messages isn't going to work the way I think you want/expect it to. (ie, you send a XEP-0033 message to two people; one of them, with a non-XEP-0033 client, responds, and the message only comes to you, and not also to the other user...correct me if I'm wrong on this). I suspect this is why you haven't seen wide adoption of XEP-0033 as its usefulness is largely dependent on other clients implementing it as well...its the age-old bootstrapping problem. </pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ JDev mailing list FAQ: <a class="moz-txt-link-freetext" href="http://www.jabber.org/discussion-lists/jdev-faq">http://www.jabber.org/discussion-lists/jdev-faq</a> Forum: <a class="moz-txt-link-freetext" href="http://www.jabberforum.org/forumdisplay.php?f=20">http://www.jabberforum.org/forumdisplay.php?f=20</a> Info: <a class="moz-txt-link-freetext" href="http://mail.jabber.org/mailman/listinfo/jdev">http://mail.jabber.org/mailman/listinfo/jdev</a> Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:JDev-unsubscribe@jabber.org">JDev-unsubscribe@jabber.org</a> _______________________________________________ </pre> </blockquote> <pre class="moz-signature" cols="72">-- Toby Schaffer email: <a class="moz-txt-link-abbreviated" href="mailto:toby_schaffer@idt.com">toby_schaffer@idt.com</a> CAD Engineer phone: 678-775-2969 Integrated Device Technology, Inc. 11555 Medlock Bridge Rd. Suite #200 Duluth, GA 30097 CONFIDENTIAL COMMUNICATION This email and any attachments thereto may contain private and confidential material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. </pre> </body> </html>