On 23.03.2017 11:05, Georg Lukas wrote: > * Florian Schmaus <f...@geekplace.eu> [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 _______________________________________________
