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,

Attachment: signature.asc
Description: This is a digitally signed message part.

Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org

Reply via email to