On Montag, 12. Februar 2018 13:53:40 CET Evgeny Khramtsov wrote: > Mon, 12 Feb 2018 09:12:02 +0100 > > Jonas Wielicki <jo...@wielicki.name> wrote: > > Could you please be specific which cache you’d like to see properly > > invalidated? Do you mean the (hash -> disco#info) cache or the > > (entity JID -> hash / disco#info) cache? > > A server can change configuration in runtime at any time, potentially > changing its disco#info. How to notify local clients about that? How to > notify clients from remote servers? How to notify connected servers after > all?
Thanks, I was thinking about client caps mostly. This is valuable input. So obviously we need a way to push updates to the peers. One way would be to use a nonza, another would be to use a message with caps payload. Irrespective of the transport used, I think the following business rule would work: * When a server has changed its disco#info and thus the Capability Hash Set, the server MUST send a push update to all of its clients and s2s connections. This doesn’t keep remote clients up-to-date. I’m not sure whether, if at all, we need this. Are there compelling use-cases? As for the transport, I generally see three options: 1. A nonza seems most reasonable from the scope point of view, because the push update should not be propagated to another stream. However, nonzas need to be negotiated. I am not sure if we want to go down that route of complexity here, especially for clients (where we’re keen on saving round-trips anyways and the complexities involved with specifying the negotiation state after SM resumption etc.). Opinions? 2. Otherwise, I’d say we simply use a <message/> addressed to the entity which is to receive the update. In case of s2s links, that would be the domain of the peer server. In case of c2s links, that would be the full JID of the client. The message would contain a single <c/> element. Type headline. This could be send unsolicitedly, I think; doesn’t need to be stored in the archive or carbon-copied either (full JID addressing makes this conformant with New Message Routing Rules; since the stanza is generated on the server, the server can take whatever measures are needed to avoid having it end up in the archives or something like that). 3. Using a full pub-sub service on the domain feels excessive, but then again, we’re already going down that route for accounts. It would allow for peers to be able to opt-in to the notifications, and it would allow remote clients to stay up-to-date. I’d like to hear your (all) input. kind regards, Jonas
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________