Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
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 li

Re: [Standards] Join and Create

2017-03-23 Thread Georg Lukas
* 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

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
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. Sor

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
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 chann

Re: [Standards] Join and Create

2017-03-23 Thread Georg Lukas
* 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

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
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. >

Re: [Standards] Join and Create

2017-03-23 Thread Dave Cridland
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 chann

Re: [Standards] Join and Create

2017-03-23 Thread Georg Lukas
* 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

Re: [Standards] Join and Create

2017-03-23 Thread Steve Kille
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 a

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
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 "jo

Re: [Standards] Join and Create

2017-03-22 Thread Steve Kille
> -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

Re: [Standards] Join and Create

2017-03-22 Thread Daurnimator
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

Re: [Standards] Join and Create

2017-03-22 Thread Steve Kille
> > 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 ___

Re: [Standards] Join and Create

2017-03-22 Thread Florian Schmaus
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 compl

[Standards] Join and Create

2017-03-22 Thread Steve Kille
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 t