<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> I hope nobody minds me bringing up an older thread... Responding to <a href="http://mail.jabber.org/pipermail/jdev/2008-June/026983.html">Nathan's original reply</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. 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. At my remote design center (exclusively Linux) we've been using MIT's Zephyr system successfully, but I'd like to get the entire company on a platform-independent (ie, Windows + Linux) system. XMPP seems like a natural choice. I've installed jabberd14 and pidgin here, and that's going ok, but the need to simply and quickly have an IM conversation with more than one person arises often. The lack of this capability is an impediment to getting Jabber accepted and used company-wide. So, without knowing the list protocol on "help wanted" announcements, is anyone interested in contracting to write a jabberd14-compatible XEP-0033 component? Getting Jabber going isn't really in my job description, so I doubt my manager'd approve spending the amount of time it'd take me to get up to speed. However, we probably have a little money to spend, so please contact me if you're both willing and able to take this on with an estimate of the time required and what you'd charge. I'm pretty sure we'd be willing to GPL the results, if that provides incentive. (I realize client support will be needed as well, but this is one step at a time...) Thanks, Jonathan Dickinson wrote: <blockquote cite="mid:A790BE8D83ECC3469047C2E344EABE613539F921D8@zamail01.k2workflow.com" type="cite"> <pre wrap="">I think we are all chasing things around in circles here. o This is all supported by XEP-0033<a class="moz-txt-link-rfc2396E" href="http://www.xmpp.org/extensions/xep-0033.html"><http://www.xmpp.org/extensions/xep-0033.html></a> o No servers support it o No clients support it Jehan to clarify your code (according to XEP-0033): ------------------------------ <message to='<a class="moz-txt-link-abbreviated" href="mailto:multicast@example.org">multicast@example.org</a>' from='<a class="moz-txt-link-abbreviated" href="mailto:sniper5@example.org/hotAirBaloon">sniper5@example.org/hotAirBaloon</a>' type='chat' xml:lang='en'> <addresses xmlns='<a class="moz-txt-link-freetext" href="http://jabber.org/protocol/address">http://jabber.org/protocol/address</a>'> <address type='cc' jid='<a class="moz-txt-link-abbreviated" href="mailto:romeo@example.net/orchard">romeo@example.net/orchard</a>' desc='Romeo'/> <address type='cc' jid='<a class="moz-txt-link-abbreviated" href="mailto:juliet@example.net/balcony">juliet@example.net/balcony</a>' desc='Juliet'/> </addresses> <body>I know you two are misbehaving.</body> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> </message> ------------------------------ PSA and JH made a really good job of that spec for one reason in particular: multicast.example.org is a component; no need to alter any client/server code and you could make this yourself today with any XMPP component library. Do we need to define another standard? No. Do we, the developers, have to sit down and look at our code tonight? Yes. Toby, today there is no support on the clients/servers (and possible components). It is something the XMPP community needs to look at, and I definitely will, but I don't know when you can expect wide-spread results. Your best bet would be to: 1. Wait for a server/component team to implement this feature and upgrade 2. Wait for a client team to implement this feature and recommend it to your clients The cocinnella chaps seem pretty good at making fast changes: maybe something for them to look at? They already have the whiteboard which has a private conference-loving implemenation - maybe someone could have a look at that code (sorry, not much use at C++ myself)? </pre> <blockquote type="cite"> <pre wrap="">-----Original Message----- From: <a class="moz-txt-link-abbreviated" href="mailto:jdev-bounces@jabber.org">jdev-bounces@jabber.org</a> [<a class="moz-txt-link-freetext" href="mailto:jdev-bounces@jabber.org">mailto:jdev-bounces@jabber.org</a>] On Behalf Of Jeff McAdams Sent: 19 June 2008 02:32 PM To: Jabber/XMPP software development list Subject: Re: [jdev] conversing with multiple users, but not MUC JabberForum wrote: </pre> <blockquote type="cite"> <pre wrap="">I think the problem of a muc derived use is about all the stuffs that many people don't care of, or don't understand. When you go to a muc, you must choose a muc server explicitely (even though it is the </pre> </blockquote> <pre wrap="">server </pre> <blockquote type="cite"> <pre wrap="">where you are already hosted) and you are proposed to chose a </pre> </blockquote> <pre wrap="">nickname </pre> <blockquote type="cite"> <pre wrap="">for instance, or whether you want to show your jid, or else being anonymous, etc. </pre> </blockquote> <pre wrap="">Except that pretty much all of that is a matter of client implementation. The spec for MUC specifically envisioned potentially using it as a seamless transition from a one-on-one discussion to a multi-way discussion. The scenario is that a one-on-one discussion is taking place and the users decide that they want to add a third person. So one of the people invites a third person into the chat. The client, and this can be completely behind the scenes, needs to go create a MUC, potentially send history to it, then send invites to the other two users with a <continue/> element. This is all described in section 7.6 of <a class="moz-txt-link-freetext" href="http://www.xmpp.org/extensions/xep-0045.html">http://www.xmpp.org/extensions/xep-0045.html</a> This protocol capability gives clients all the tools they need to seamlessly convert a one-on-one to a quick ad-hoc sort of MUC chat with multiple people. The user need not be even aware that MUC is being used to do it. -- Jeff McAdams "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin </pre> </blockquote> <pre wrap=""> _______________________________________________ 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>