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]
_______________________________________________
