[jdev] conversing with multiple users, but not MUC

[Toby Schaffer]

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
>> <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. 
>>     
>
> 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: 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/43072356/attachment-0002.htm>