On 23.03.2017 04:14, Daurnimator wrote:
> On 23 March 2017 at 01:40, Florian Schmaus <[email protected]> wrote:
>> On 22.03.2017 12:53, Steve Kille wrote:
>>> I think that keeping Create and Join separate is the right thing.
>>
>> They can and should be separate, but I think there needs to be a third
>> operation "join-and-maybe-create". Otherwise the protocol is incomplete
>> and broken.
>>
>>> I feel that we have enough complexity with the modular operations, without
>>> creating compound operations that will have whole new classes of error to
>>> consider
>>
>> How about making this an optional feature in an add-on XEP?
> 
> Couldn't this be a create followed by a join?
> If the channel already exists, then the create would return an error
> (which you can ignore).

That is basically what Smack does [1], as I've written in [2], but is
not sufficient.

A simple example:

Consider an chess-game service build on top of MIX. Tim and Tom want to
play a game and agree on the "TimAndTomsGame" as name. Now both clients
want to join-and-maybe-create the TimAndTomsGame MIX channel.

Currently a client implementation will look something like this (note
that it does matter if you try to create first and then join, or the
other way around):

result = join(TimAndTomsGame)
if (result == channel-does-not-exist) {
   // A
   result = create(TimAndTomsGame)
   if (result = channel-does-exist) {
      // B
      result = join(TimAndTomsGame)
   }
}

This tries to fix all the races, but fails. A is what you mentioned. But
if Tom decides that he has waited long enough while Tim is at B, and
leaves the channel, upon which the channel will get auto-destroyed, then
Tim will get a channel-does-not-exist result using this logic.

The only way to solve this is to make this an atomic operation at
protocol level. Which is trivial to add, simply define an IQ which has
"two" child elements, <join/> and <create/>, and easy to implement
server side (and, of course, client side).

- Florian

1:
https://github.com/igniterealtime/Smack/blob/08c228ef99b59c7c16b44941875e1ea640db3b62/smack-extensions/src/main/java/org/jivesoftware/smackx/pubsub/PubSubManager.java#L272
1: https://mail.jabber.org/pipermail/standards/2017-March/032419.html


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to