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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to