Re: [jdev] conversing with multiple users, but not MUC
I hope nobody minds me bringing up an older thread... Responding to Nathan's original reply http://mail.jabber.org/pipermail/jdev/2008-June/026983.html 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: I think we are all chasing things around in circles here. o This is all supported by XEP-0033http://www.xmpp.org/extensions/xep-0033.html o No servers support it o No clients support it Jehan to clarify your code (according to XEP-0033): -- message to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]/hotAirBaloon' type='chat' xml:lang='en' addresses xmlns='http://jabber.org/protocol/address' address type='cc' jid='[EMAIL PROTECTED]/orchard' desc='Romeo'/ address type='cc' jid='[EMAIL PROTECTED]/balcony' desc='Juliet'/ /addresses bodyI know you two are misbehaving./body threade0ffe42b28561960c6b12b944a092794b9683a38/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)? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: 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 server where you are already hosted) and you are proposed to chose a nickname for instance, or whether you want to show your jid, or else being anonymous, etc. 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 http://www.xmpp.org/extensions/xep-0045.html This protocol capability gives clients all the tools they need to seamlessly convert a one-on-one
Re: [jdev] conversing with multiple users, but not MUC
Toby Schaffer wrote: I hope nobody minds me bringing up an older thread... Responding to Nathan's original reply http://mail.jabber.org/pipermail/jdev/2008-June/026983.html 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. 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. 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. 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. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
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: Toby Schaffer wrote: I hope nobody minds me bringing up an older thread... Responding to Nathan's original reply http://mail.jabber.org/pipermail/jdev/2008-June/026983.html 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. 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. 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. 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. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___ -- Toby Schaffer email: [EMAIL PROTECTED] 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. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Gajim SVN (and the soon-coming 0.12 release) allows converting a chat to a groupchat. It's not that seamless atm, but we're working on that. This works just fine together with ejabberd 2.x. -- Jonathan signature.asc Description: PGP signature ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Really, this is a client implementation issue. You see the MUC room as too formal, when in fact, they're completely throw-away, and the client could handle it behind the scenes. Generate a random chat room, invite everyone in, have your conversation, and leave easily, without the formal interface of a full-on MUC room. This is one of the disadvantages of XMPP not being tightly integegrated with a service (anyone can run XMPP in whatever way they want), so it seems to me that there needs to be a proceedural XEP and maybe some service discovery for default place on the server to make throw-away MUC rooms so that the client doesn't have to be configured for a particular MUC component and doesn't have to assume either. In short, yes, MUC is the way to do it, and that's what it's there to partially serve. There just needs to be a way for clients to distinguish formal rooms with informal ones, and I think your feature request would be handled. On Wed, Jun 18, 2008 at 3:18 PM, Toby Schaffer [EMAIL PROTECTED] wrote: I'm trying to get Jabber going at my company for IM and chat, and so far it's working ok. But one major roadblock is the lack of the ability to have an n-way conversation (eg, I want to talk to two coworkers, and only those two, and have all three of us see all the replies) without using a chat room. It appears XEP-0033 (extended stanza addressing) describes a way to do this with email-style cc and bcc. However, I can't find any server - or even a client - which supports this. How do people hold n-way conversations now? I was told in one forum that everyone just uses MUC, but it seems very awkward to have to create or modify a room to have a conversation with a given set of multiple recipients. Am I missing something obvious? Thanks. -- Toby Schaffer ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___ ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
2008/6/19 Tomasz Sterna [EMAIL PROTECTED]: Dnia 2008-06-18, śro o godzinie 23:18 -0700, Nathan Fritz pisze: Really, this is a client implementation issue. [...] Really? yes - What if there is no MUC server available in your server disco? Implementation issue - What if there is no MUC server available (you're on a closed network)? Ask your admin for a MUC service - What if there is no server available at all (you're on an ad-hoc network using XEP-0174: Link-Local Messaging)? Do people who use this need MUC? -- Mvg, Sander Devrieze. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Dnia 2008-06-19, czw o godzinie 11:49 +0200, Sander Devrieze pisze: Do people who use this need MUC? No. They happily use Skype where this (and many, many more) just works. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED] ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Right, I do think we need a XEP to make this just work but it should be some simple service discovery to get the default MUC implementation and some identifier for the client that this is a casual groupchat. - What if there is no MUC server available in your server disco? It's a requirement. - What if there is no MUC server available (you're on a closed network)? It's a requirement. - What if there is no server available at all (you're on an ad-hoc network using XEP-0174: Link-Local Messaging)? Uh, good point. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
I think http://www.xmpp.org/extensions/inbox/private-muc.html is what you guys are looking for. - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ On Thu, Jun 19, 2008 at 12:24 PM, Nathan Fritz [EMAIL PROTECTED] wrote: Right, I do think we need a XEP to make this just work but it should be some simple service discovery to get the default MUC implementation and some identifier for the client that this is a casual groupchat. - What if there is no MUC server available in your server disco? It's a requirement. - What if there is no MUC server available (you're on a closed network)? It's a requirement. - What if there is no server available at all (you're on an ad-hoc network using XEP-0174: Link-Local Messaging)? Uh, good point. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___ ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Hello, 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 server where you are already hosted) and you are proposed to chose a nickname for instance, or whether you want to show your jid, or else being anonymous, etc. In a basic multi-user discussion, people just want to speak with several people. They don't want to be proposed to have another nickname than the one they already have, they don't care about being anonymous (because anyway in such case, they discuss about known people, even probably people in their roster) and they don't want to have to find a server which propose such a muc service (because they don't understand what means muc, and what is a server). For instance I may just be discussing with a friend, and I see another common friend connecting. So I say eh let's invite Jo to speak with us, I click the button invite someone in this discussion, and now he simply can speak with us. So of course, you could do this with a client implementation using muc: it would check on your local server whether a muc service exists, create a private muc, don't ask to hide your jid or to choose a nickname, don't ask a room title, make it private, etc. But I think this is complicated compared to a system of multi-recipient. You simply send a message with several recipients. And a conversation thread element (cf. 4.5 of rfc3921) is welcome to follow this specific discussion (enabling then to distinguish several discussions opened with the same user for instance). So it would give something like: Code: message to='[EMAIL PROTECTED]/orchard,[EMAIL PROTECTED]/balcony' from='[EMAIL PROTECTED]' type='chat' xml:lang='en' bodyHello Romeo, hello Juliet. How are you?/body threade0ffe42b28561960c6b12b944a092794b9683a38/thread /message I would say that if you don't specify a thread, then this would be only a message sent to several people, but independently (they won't know all the recipients). What do you think of this? Jehan -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=302 ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
And to add more details, I would say that maybe a server receiving this will send to Romeo this message, with a new 'cc' option: Code: message to='[EMAIL PROTECTED]/orchard' cc='[EMAIL PROTECTED]/balcony' from='[EMAIL PROTECTED]' type='chat' xml:lang='en' bodyHello Romeo, hello Juliet. How are you?/body threade0ffe42b28561960c6b12b944a092794b9683a38/thread /message Code: And when Romeo answer to this, his client would generate: Code: message from='[EMAIL PROTECTED]/orchard' to='[EMAIL PROTECTED]/balcony,[EMAIL PROTECTED]' type='chat' xml:lang='en' bodyHej all! I'm fine me. What about you too?/body threade0ffe42b28561960c6b12b944a092794b9683a38/thread /message Code: -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=302 ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
JabberForum wrote: 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 server where you are already hosted) and you are proposed to chose a nickname for instance, or whether you want to show your jid, or else being anonymous, etc. 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 http://www.xmpp.org/extensions/xep-0045.html 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 signature.asc Description: OpenPGP digital signature ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
I think we are all chasing things around in circles here. o This is all supported by XEP-0033http://www.xmpp.org/extensions/xep-0033.html o No servers support it o No clients support it Jehan to clarify your code (according to XEP-0033): -- message to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]/hotAirBaloon' type='chat' xml:lang='en' addresses xmlns='http://jabber.org/protocol/address' address type='cc' jid='[EMAIL PROTECTED]/orchard' desc='Romeo'/ address type='cc' jid='[EMAIL PROTECTED]/balcony' desc='Juliet'/ /addresses bodyI know you two are misbehaving./body threade0ffe42b28561960c6b12b944a092794b9683a38/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)? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: 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 server where you are already hosted) and you are proposed to chose a nickname for instance, or whether you want to show your jid, or else being anonymous, etc. 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 http://www.xmpp.org/extensions/xep-0045.html 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 ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Dickinson Sent: 19 June 2008 04:08 PM To: Jabber/XMPP software development list Subject: Re: [jdev] conversing with multiple users, but not MUC ... 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. Correction: no need to alter any server code. ... ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
On 06/19/2008 4:39 AM, Norman Rasmussen wrote: I think http://www.xmpp.org/extensions/inbox/private-muc.html is what you guys are looking for. Yes, OLPC uses something very much like that in the link-local case. So we need to poke Dave Cridland about finishing the proposal. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Ok this XEP 33 is a nice one and is apparently what I was wishing with my clumsy example. :-) I will have a look at this someday when I will have time (again another XEP to read!). -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=302 ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
2008/6/19 Jonathan Dickinson [EMAIL PROTECTED]: I think we are all chasing things around in circles here. o This is all supported by XEP-0033http://www.xmpp.org/extensions/xep-0033.html o No servers support it o No clients support it Jehan to clarify your code (according to XEP-0033): -- message to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]/hotAirBaloon' type='chat' xml:lang='en' addresses xmlns='http://jabber.org/protocol/address' address type='cc' jid='[EMAIL PROTECTED]/orchard' desc='Romeo'/ address type='cc' jid='[EMAIL PROTECTED]/balcony' desc='Juliet'/ /addresses bodyI know you two are misbehaving./body threade0ffe42b28561960c6b12b944a092794b9683a38/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)? Mats does not has much time these days. btw: Coccinella is Tcl/Tk; not C++ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: 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 server where you are already hosted) and you are proposed to chose a nickname for instance, or whether you want to show your jid, or else being anonymous, etc. 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 http://www.xmpp.org/extensions/xep-0045.html 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 ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___ -- Mvg, Sander Devrieze. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
On 06/19/2008 8:27 AM, JabberForum wrote: Ok this XEP 33 is a nice one and is apparently what I was wishing with my clumsy example. :-) I will have a look at this someday when I will have time (again another XEP to read!). Yes we have a lot of XEPs. The point of all those is to give you all the tools you need to build the applications you want to build. But somehow people keep thinking up new features we might need... /psa smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
Peter Saint-Andre;1152 Wrote: Yes we have a lot of XEPs. The point of all those is to give you all the tools you need to build the applications you want to build. But somehow people keep thinking up new features we might need... Yes. But can you really blame us? I will speak for my own, but I guess this applies also to many other people: we know a small subset of XMPP, so obviously we try to build from it what we would really like or prefer (compared to what we know). And then we discover something similar or close exists. I would love to know all the XEP, or better working with XMPP (for now, I just get interested in it during my leisure time, which is small). And I assure you that I often search among all the XEPs for something I need, but this is not always easy. :-) -- Jehan Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=302 ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] conversing with multiple users, but not MUC
On 06/19/2008 12:48 PM, JabberForum wrote: Peter Saint-Andre;1152 Wrote: Yes we have a lot of XEPs. The point of all those is to give you all the tools you need to build the applications you want to build. But somehow people keep thinking up new features we might need... Yes. But can you really blame us? I will speak for my own, but I guess this applies also to many other people: we know a small subset of XMPP, so obviously we try to build from it what we would really like or prefer (compared to what we know). And then we discover something similar or close exists. I would love to know all the XEP, or better working with XMPP (for now, I just get interested in it during my leisure time, which is small). And I assure you that I often search among all the XEPs for something I need, but this is not always easy. :-) Sure, that's why people post to this list and we point them in the right direction. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
