29 Aug
2024
29 Aug
'24
1:04 p.m.
Ultimately, my argument is that I want to set autojoin to false and for it to remain
false, and not to be changed when I happen to join a room; obviously when it's now
used in place of 'joined', that's unavoidable. But then, I never want to
autojoin a room, so arguably that should be a client setting and the attribute is useless
to me too.
I think you are a bit late to the party there.
Since years in Gajim, we don't expose the user to protocol details of bookmarks. We
removed all mentions of bookmarks. No user does need to know the protocol details how a
client syncs known chats. Why would a user need to learn what "autojoining a
MUC" means when using Gajim.
I think your fear that this language change in the XEP makes your usage impossible is
overblown.
What the XEP describes for me is a fair, common sense implementation, in absence of any
advanced settings that your client may offer.
I think all your wishes can be implemented by a client who offers more control for that,
call it "advanced multi device muc join settings".
Is this discussion maybe just a different opinion on what "SHOULD" entails?
When i read the RFC keyword definition, it seems ok for me that a developer offers
settings that ignore this SHOULD.
I think there are valid use cases for ignoring the autojoin flag, or storing join
information locally instead of syncing it to pubsub etc. and this SHOULD would not stop me
implementing settings to satisfy such use cases.
Regards
Philipp