[jdev] conversing with multiple users, but not MUC

Tue Jul 1 09:17:59 CDT 2008

I hope nobody minds me bringing up an older thread... Responding to 
Nathan's original reply 
<https://www.jabber.org/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-0033<http://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='multicast at example.org'
>   from='sniper5 at example.org/hotAirBaloon'
>   type='chat'
>   xml:lang='en'>
>
>    <addresses xmlns='http://jabber.org/protocol/address'>
>        <address type='cc' jid='romeo at example.net/orchard' desc='Romeo'/>
>        <address type='cc' jid='juliet at example.net/balcony' 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)?
>
>   
>> -----Original Message-----
>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] 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: JDev-unsubscribe at jabber.org
> _______________________________________________
>
>
>   

-- 
Toby Schaffer                          email: toby_schaffer at idt.com
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20080701/b701a0f2/attachment-0002.htm>