Matthew Wild wrote:
On Wed, Aug 13, 2008 at 6:41 PM, Justin Karneges <[EMAIL PROTECTED]> wrote:There are many places where a UUID may be appropriate, but I don't think this is one of them. You're desiring an unique handle to the MUC service, and the MUC itself is really the authority for that.How about: Client requests to create a room, using the best hash it can muster: <presence to='[EMAIL PROTECTED]/nick'' from='[EMAIL PROTECTED]/home'> <x xmlns='http://jabber.org/protocol/muc'/> <unique xmlns='http://jabber.org/protocol/muc#unique' /> </presence> Server supports unique extension, and the room already existed, so it replies with a new one: <presence from='[EMAIL PROTECTED]/nick'' to='[EMAIL PROTECTED]/home'> <unique xmlns='http://jabber.org/protocol/muc#unique'>[EMAIL PROTECTED]/nick</unique> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='owner' role='moderator'/> <status code='110'/> <status code='201'/> </x> </presence> This saves the round-trip, and the worst case result (the server doesn't support the extension and the hash collides) is the same as what we have now.
That seems like a reasonable approach. The only downside I see (other than the fact that we're painting the bikeshed ;-) is that the client might add a privacy rule for [EMAIL PROTECTED] when it attempts to create the room, so it might never receive the presence from [EMAIL PROTECTED]
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
