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
* 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
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
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
* 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
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.
>
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
* 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
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
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
> -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
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
>
> 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
___
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
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
15 matches
Mail list logo