On 2020/05/24, Mathieu Pasquet wrote: > Greetings, > > I want to raise an issue that appears with bookmarks in their current > form in the multi-client scenario. It appears as long as we have more > than one client, and gets worse for every added client and MUC bookmark. > > XEP-0048 and XEP-0402 both re-use the <conference/> element, which has > an autojoin flag. In a single-client scenario this is fine because that > represents what the user wants in terms of joined rooms. In a > multi-client scenario however, that quickly changes as you probably do > not want the same view everywhere.
I agree. > The use cases I have in mind are a bit extreme (e.g. people with > 100 > MUCs in their autojoined bookmarks), which are unusable on mobile, for > example, where screen space is limited and you probably want to limit > yourself to the "important" ones. Or when joining big IRC channels with > more than 1000 users, you also do not want that on mobile as that much > activity is never good for battery life, however optimized the client > might be. Even for smaller cases, such as 20-30 rooms, this can be a > limiting factor. > > Bookmarks in themselves only represent MUCs we want to keep in memory, > and that is fine. However tying the "autojoin" attribute in there means > we are now syncing client state, and that is not often desirable, for > the reasons stated above (different constraints, different platforms, > different attention spans). > > The following is probably over-engineered for a nerdy edge case, but one > viable solution would be the ability to manage sets of client "profiles" > which would hold client state independently from bookmarks. This could > be stored in PEP as well, and could be a list of pubsub URIs to the > stored bookmarks. Removing a bookmark would automatically remove the > autojoin in all profiles that link to it. I'm thinking that even if some clients don't want to implement support for multiple profiles, they could "just" implement support for a single/default profile, still allowing advanced clients to use different ones. This would allow for the bookmark list would to be a bookmark list and not a syncing mechanism. That list could be used in various cases where completion/suggestions are helpful. -- Maxime “pep” Buquet
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
