[Standards] Entity Capabilities 2.0
jonas at wielicki.name
Mon Feb 12 12:14:03 UTC 2018
On Montag, 12. Februar 2018 13:53:40 CET Evgeny Khramtsov wrote:
> Mon, 12 Feb 2018 09:12:02 +0100
> Jonas Wielicki <jonas at 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
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
I’d like to hear your (all) input.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards