Hi, The problem is there are no rules what goes into which profile.
If i add a bookmark as a desktop client, i don't know if it should go into the mobile profile or not. And btw we try to abstract bookmarks away from the user, so managing profiles of bookmarks for different devices is exactly not the direction i want to go. So either this can be determined automatically without user input (i doubt it) or a simple local autojoin list where the user simply has to manually join bookmarks is better in my opinion. Regards Philipp Am So., 24. Mai 2020 um 01:17 Uhr schrieb Maxime Buquet <p...@bouah.net>: > 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 > _______________________________________________ > 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 _______________________________________________
