Am 22. März 2018 08:28:21 MEZ schrieb Matthew Wild <mwi...@gmail.com>: >On 21 March 2018 at 17:27, Maxime Buquet <p...@bouah.net> wrote: >> On 2018/03/21, Sam Whited wrote: >>> On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote: >>> > I’d argue (and did at the Summit) that the opposite is true and >that if >>> > we want (especially impromptu) MUC to start working nicely across >>> > multiple accounts we need clients to react to the user leaving >rooms >>> > manually by disabling the autojoin and then having other clients >leave >>> > as well. They only joined because the autoflag was set, so isn’t >it >>> > logical for them to leave when it’s no longer set? >>> >>> I agree with this; when I do something on one client, I almost >always want it synced to my other clients. Room joining and parting is >the same. Similarly, just because my connection dropped and came back >up a moment later doesn't mean I should suddenly not be joined to rooms >anymore. If I'm in a room, I should autojoin it from all my clients on >startup, if I close the room, it should close immediately in my other >clients and no longer be autojoined on startup. >> >> When I do join or part on one client, I almost never want it synced >to my >> other clients. I have pretty different use between clients. > >That's fine. To be honest, I'm the same. I have a couple of >low-traffic rooms that I join on my mobile, and yet I am in dozens of >rooms on my desktop client. I'd guess many people, especially "power >users" are not very different. > >It doesn't change my opinion about the protocol though. The whole >purpose of bookmarks is for sharing between clients. If you join a >room on one client and it's only for that client, then it shouldn't be >set to 'autojoin' in a data store that is shared across all your >devices. > >We're discussing the protocol, but there is nothing stopping clients >having their own overrides (i.e. local autojoin rooms). This could be >as simple as, when you join a room for the first time "Do you want to >join this room on all devices?" -> if the user answers positively, >then a bookmark with 'autojoin' is set. If not, a bookmark may still >be set, but the autojoin flag is only remembered locally. > >And while we're here, I think "autojoin" is a silly concept. A client >should just remember what rooms it has open, and keep them open. If I >close my client and re-open it (or it crashed, or my computer crashed, >etc.), I'd expect to still be in the same rooms, unless I explicitly >asked it to leave them.
With a pure JavaScript browser client, where people can use public computers or a friend's computer, I don't store all this data for longer than the session (which ends when you close the tab), so every time someone logs in, it's as if they're logging in for the very first time. In this use case I find autojoin very useful as there is no other memory. JC >> If my connection dropped and came back a moment later, I would want >my >> client to rejoin MUCs I was in. I use bookmarks mostly as a way to >> remember MUC JIDs, not to know which state my clients should be in. > >That's fine, and I see that as a completely valid use of the protocol. >Just don't set autojoin on any of your bookmarks, and use clients that >remember which rooms they are joined to. > >Regards, >Matthew >_______________________________________________ >Standards mailing list >Info: https://mail.jabber.org/mailman/listinfo/standards >Unsubscribe: standards-unsubscr...@xmpp.org >_______________________________________________ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
