Flo,
I'm not convinced by this example.
MIX is primarily oriented for end users, not as a building block like
PubSub. I don't see this example as a target application and the issue
seems quite pathological to me
Steve
> > 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
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
