Re: [Standards] XEP-0045: How to signal tombstones for destroyed rooms?
Either include status code 110 in the unavailable presence or use an error presence. The XEP is a bit fuzzy on when to use what. But I won’t be able to parse an unavailable w/o 110 So in your case (a join attempt to the tombstone) I have a slight personal preference toward error; But I’m ok with both as long as the unavailable has a 110. 2018-07-11 4:02 GMT+02:00 Kim Alvefur : > Hello list, > > I have implemented tombstones for destroyed MUC rooms. My reading of the > sacred texts did not give me enlightenment as how to inform someone > who's attempting to enter the remains of such a place. I've so far opted > to return an with the same child > that was in the inital announcement of the rooms destruction. > > Of the clients I’ve tested so far, only Gajim seems to understand this. > Swift says something unspecific about failure to enter the room, while > Pidgin and poezio say nothing. > > So basically, this is the reply one gets to a MUC join: > > ``` xml > from="a@gc.localhost/n"> > http://jabber.org/protocol/muc#user;> > > You see only a crater. > > > > ``` > > Does this make sense? > > -- > Kim "Zash" Alvefur > Destroyer of rooms > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045: How to signal tombstones for destroyed rooms?
On 11.07.2018 07:52, Jonas Wielicki wrote: > On Mittwoch, 11. Juli 2018 04:02:23 CEST Kim Alvefur wrote: >> Hello list, >> >> I have implemented tombstones for destroyed MUC rooms. My reading of the >> sacred texts did not give me enlightenment as how to inform someone >> who's attempting to enter the remains of such a place. I've so far opted >> to return an with the same child >> that was in the inital announcement of the rooms destruction. >> >> Of the clients I’ve tested so far, only Gajim seems to understand this. >> Swift says something unspecific about failure to enter the room, while >> Pidgin and poezio say nothing. >> >> So basically, this is the reply one gets to a MUC join: >> >> ``` xml >> > from="a@gc.localhost/n"> http://jabber.org/protocol/muc#user;> >> >> You see only a crater. >> >> >> >> ``` >> >> Does this make sense? > > Is there a reason to not use a presence type="error"? I’d expect clients to > handle those already. Yep, Smack would handle an 'error'. I also lean towards 'error'. Any reason why you choose 'unavailable'? IIRC 'error' presences are usually send as a result of another presence, whereas 'unavailable' presences are usually send independently of other prior presences. Hence 'error' seems more suited in this case. - 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] XEP-0045: How to signal tombstones for destroyed rooms?
On 11 Jul 2018, at 03:02, Kim Alvefur wrote: > > Hello list, > > I have implemented tombstones for destroyed MUC rooms. My reading of the > sacred texts did not give me enlightenment as how to inform someone > who's attempting to enter the remains of such a place. I've so far opted > to return an with the same child > that was in the inital announcement of the rooms destruction. > > Of the clients I’ve tested so far, only Gajim seems to understand this. > Swift says something unspecific about failure to enter the room, while > Pidgin and poezio say nothing. > > So basically, this is the reply one gets to a MUC join: > > ``` xml > from="a@gc.localhost/n"> > http://jabber.org/protocol/muc#user;> > >You see only a crater. > > > > ``` > > Does this make sense? I’d go slightly differently from the other replies - if you want it to be clear that the room is destroyed and tombstoned, I would send an artificial join success followed immediately by room destruction, as we *do* have a way to signal destruction once you’re in the room. I would expect all clients to be happy with that and it’s clear that the room is destroyed. I think any other mechanism and you’re either sacrificing knowledge of the tombstone or knowledge the join failed, depending on implementations. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045: How to signal tombstones for destroyed rooms?
On Wed, Jul 11, 2018 at 07:52:55AM +0200, Jonas Wielicki wrote: > Is there a reason to not use a presence type="error"? I’d expect clients to > handle those already. Mostly becasue I simply copied code from the room destruction handler. > I’d use a type error, which encodes the semantics perfectly. > also allows for permanent redirects (which I think does, too). This makes sense. Even Pidgin seems to understand it. Incidentally, guess which client doesnt’t handle that ;) -- Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Exact hint for Result Set Management
I recently submitted PR #672 to the xeps repo https://github.com/xsf/xeps/pull/672 to make users of RSM, like MAM, aware whether the result is exact or not. It received some scepticism from the council members in today's council meeting. I am to blame here as I thought the abstract motivation in the commit message was enough. It appears it wasn't. While I think multiple applications could exploit that information, my particular motivation was MAM. Consider the scenario where you have a master archive and a local archive. The local archive may have multiple holes at unknown locations. Now you want to sync your local archive from the master using MAM/RSM. If you don't know whether or not the MAM RSM results are exact, you need resort to basically re-syncing the complete archive from the master. But if you know that the results are exact, you could use count-only MAM RSM queries (XEP-0059 § 2.7) and the unique-and-stable IDs of the archived messages to effectively determine the holes and fill them up, using a simple bisection algorithm which compares the message count with the expect unique-and-stable archive message ID. This saves a lot of roundtrips and especially transferred data when syncing the archive. I also like to point out that the changes in #672 are backwards compatible. Not namespace bump required. I'm off to barbecue, but I'm still looking forward to your feedback. - 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] Exact hint for Result Set Management
On 11.07.2018 18:01, Matthew Wild wrote: > On 11 July 2018 at 16:33, Florian Schmaus wrote: >> I recently submitted PR #672 to the xeps repo >> >> https://github.com/xsf/xeps/pull/672 >> >> to make users of RSM, like MAM, aware whether the result is exact or >> not. It received some scepticism from the council members in today's >> council meeting. I am to blame here as I thought the abstract motivation >> in the commit message was enough. It appears it wasn't. >> >> While I think multiple applications could exploit that information, my >> particular motivation was MAM. Consider the scenario where you have a >> master archive and a local archive. The local archive may have multiple >> holes at unknown locations. Now you want to sync your local archive from >> the master using MAM/RSM. > > I'm not keen on this solution for the premise you've given. > > I don't believe that when using MAM correctly you would ever end up > with "holes at unknown locations" in your local archive. I don't think > that encouraging people to use a "bisection algorithm" is the right > thing to do. So you don't want MAM users to be able to efficiently sync archives with multiple holes by a simple change because you do not want MAM to be used in scenarios where this could happen? Even if we would live in a world where such MAM archives are never going to happen, adding the exact hint to RSM is worthwhile. From a generic, non MAM-specific point-of-view, RSM is eventually used to sync data, and for that you often want to now if the RSM metadata is exact or not. My MAM example is just one illustration of that. It always appeared like an afterthought that RSM does not allow the RSM data originator to signal if the numbers are exact or not. The proposed change tries to fix that. - 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] Exact hint for Result Set Management
On 11 July 2018 at 16:33, Florian Schmaus wrote: > I recently submitted PR #672 to the xeps repo > > https://github.com/xsf/xeps/pull/672 > > to make users of RSM, like MAM, aware whether the result is exact or > not. It received some scepticism from the council members in today's > council meeting. I am to blame here as I thought the abstract motivation > in the commit message was enough. It appears it wasn't. > > While I think multiple applications could exploit that information, my > particular motivation was MAM. Consider the scenario where you have a > master archive and a local archive. The local archive may have multiple > holes at unknown locations. Now you want to sync your local archive from > the master using MAM/RSM. I'm not keen on this solution for the premise you've given. I don't believe that when using MAM correctly you would ever end up with "holes at unknown locations" in your local archive. I don't think that encouraging people to use a "bisection algorithm" is the right thing to do. If this is a problem you are facing, let's go back to the basics and figure out how you end up with holes at unknown locations in your archive. And we can fix that. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
