Re: [Standards] Join and Create
On 23.03.2017 14:31, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 14:25]: >> It is the same feature request for PubSub/PEP. For example when using >> OMEMO you always want to subscribe-and-maybe-create the devicelist node. > > I can see how an UPSERT operation is useful … This is really like an UPSERT, but that is my second feature request where I actually wrote already an ProtoXEP for http://geekplace.eu/xeps/xep-cap/xep-cap.html It is simply CAS for PubSub/PEP, to avoid races when updating nodes. While working on OMEMO, we saw that this may be an useful server feature. Note sure if MIX would benefit form it to (e.g., when updating the channel topic). I'd probably will submit it soon to council. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
* Florian Schmaus [2017-03-23 14:25]: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. I can see how an UPSERT operation is useful on a resource that is exclusively owned by you, but not on a "public asset" shared with other users. > > - Named public long-lived MIXes: you want to either be the owner of it > > or have the creation fail. > You do sometimes have exclusive races against other resources of your JID. Like... when you attempt to create the same channel on two different devices, at the same time? Seriously, there is no such problem with MIX, because the first client creating the MIX will get it pushed into the roster and all the others will be auto-subscribed, or something along these lines. The race condition I see as problematic is different users trying to create the same MIX. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 14:25, Florian Schmaus wrote: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. > Some goes for the XEP-0080 geoloc node. It would be nice if PubSub would > provide that as primitive. Sorry, not subscribe-and-maybe-create, but retrieve-and-maybe-create. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 11:05, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 10:11]: >> That does work if the name of the channel can be random (nameless). But >> I believe that there will be use cases where the name of the channel >> needs to be fixed. > > Yes, there are use cases where a fixed channel name is needed. But do > you really want to end up in a situation where a race condition decides > on who will become the owner of that channel, and where you'll > accidentally expose your full JID to a third party by join-or-creating > some milliseconds too late? See comment below. >> For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the >> situation here is not so bad, because the nodes don't get deleted usually). > > Sorry, I can't follow you. What's the relevance of the current > discussion to OMEMO etc? It is the same feature request for PubSub/PEP. For example when using OMEMO you always want to subscribe-and-maybe-create the devicelist node. Some goes for the XEP-0080 geoloc node. It would be nice if PubSub would provide that as primitive. >> But yeah, § 6.5.3 could be sufficient in most cases. However, I still >> feel like having an optional atomic join-or-maybe-create operation would >> be nice to have. > > I have a contrary opinion. Join-or-maybe-create is the wrong solution > for the two MIX use cases I see, and it would make implementors take > nasty shortcuts. > > - Named public long-lived MIXes: you want to either be the owner of it > or have the creation fail. You do sometimes have exclusive races against other resources of your JID. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
* Florian Schmaus [2017-03-23 10:11]: > That does work if the name of the channel can be random (nameless). But > I believe that there will be use cases where the name of the channel > needs to be fixed. Yes, there are use cases where a fixed channel name is needed. But do you really want to end up in a situation where a race condition decides on who will become the owner of that channel, and where you'll accidentally expose your full JID to a third party by join-or-creating some milliseconds too late? > For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the > situation here is not so bad, because the nodes don't get deleted usually). Sorry, I can't follow you. What's the relevance of the current discussion to OMEMO etc? > But yeah, § 6.5.3 could be sufficient in most cases. However, I still > feel like having an optional atomic join-or-maybe-create operation would > be nice to have. I have a contrary opinion. Join-or-maybe-create is the wrong solution for the two MIX use cases I see, and it would make implementors take nasty shortcuts. - Named public long-lived MIXes: you want to either be the owner of it or have the creation fail. - Anon/private MIXes: just use §6.5.3 Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23.03.2017 09:38, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 08:22]: >> 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. > > I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use" > is meant for. One of the two creates such a "nameless" channel and sends > an invitation, there is really no need to have both parties trying to > create it, or any kind of out-of-band name arbitration. That does work if the name of the channel can be random (nameless). But I believe that there will be use cases where the name of the channel needs to be fixed. For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the situation here is not so bad, because the nodes don't get deleted usually). But yeah, § 6.5.3 could be sufficient in most cases. However, I still feel like having an optional atomic join-or-maybe-create operation would be nice to have. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23 March 2017 at 08:38, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 08:22]: >> 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. > > I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use" > is meant for. One of the two creates such a "nameless" channel and sends > an invitation, there is really no need to have both parties trying to > create it, or any kind of out-of-band name arbitration. > > Just because in MUC there was no explicit way to create such a private > channel, we don't need to mimic the old behavior in MIX. > > I'm not convinced by this example, and I think there is no other > compelling use case for that functionality. +1. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
* Florian Schmaus [2017-03-23 08:22]: > 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. I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use" is meant for. One of the two creates such a "nameless" channel and sends an invitation, there is really no need to have both parties trying to create it, or any kind of out-of-band name arbitration. Just because in MUC there was no explicit way to create such a private channel, we don't need to mimic the old behavior in MIX. I'm not convinced by this example, and I think there is no other compelling use case for that functionality. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
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, and , and easy to implement server side (and,
of
> course, client side).
>
> - Florian
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Join and Create
On 23.03.2017 04:14, Daurnimator wrote:
> On 23 March 2017 at 01:40, Florian Schmaus 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, and , 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
signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Join and Create
> -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of > Daurnimator > Sent: 23 March 2017 03:15 > To: XMPP Standards > Subject: Re: [Standards] Join and Create > > On 23 March 2017 at 01:40, Florian Schmaus 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). [Steve Kille] That feels sensible to me. I am not really seeing the benefit of adding a new operation Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
On 23 March 2017 at 01:40, Florian Schmaus 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). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
> > 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. [Steve Kille] Can you outline the scenario in which such an operation would be useful? Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Join and Create
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? - Florian >> -Original Message- >> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian >> Schmaus >> Sent: 22 March 2017 11:49 >> To: XMPP Standards >> Subject: Re: [Standards] MIX (XEP-0369) update to version 0.9 >> >> On 22.03.2017 11:44, Steve Kille wrote: >>> I believe that I have addressed all outstanding comments, so if you >>> think something has been missed, let me know >> >> Not sure if it qualifies as "outstanding comment" :), but >> https://mail.jabber.org/pipermail/standards/2017-March/032419.html >> >> - Florian >> > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Join and Create
Florian, I think that keeping Create and Join separate is the right thing. I do not plan to make changes unless I see very strong support for this. 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 Steve > -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian > Schmaus > Sent: 22 March 2017 11:49 > To: XMPP Standards > Subject: Re: [Standards] MIX (XEP-0369) update to version 0.9 > > On 22.03.2017 11:44, Steve Kille wrote: > > I believe that I have addressed all outstanding comments, so if you > > think something has been missed, let me know > > Not sure if it qualifies as "outstanding comment" :), but > https://mail.jabber.org/pipermail/standards/2017-March/032419.html > > - Florian > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
