[Standards] NEW: XEP-0390 (Entity Capabilities 2.0)

Evgeny Khramtsov xramtsov at gmail.com
Sat May 27 08:59:55 UTC 2017

Sat, 27 May 2017 10:22:27 +0200
Daniel Gultsch <daniel at gultsch.de> wrote:

> 2017-05-27 6:39 GMT+02:00 Evgeny Khramtsov <xramtsov at gmail.com>:
> > Fri, 26 May 2017 18:41:17 +0200
> > Daniel Gultsch <daniel at gultsch.de> wrote:
> >  
> >> would sending in presence work?  
> >
> > If we choose to use presences, then why even bother with putting
> > caps in features?  
> Fair question. Maybe to avoid a race condition where the client
> queries the disco node before receiving the presence?
> >
> > If we choose to use stream elements, we can send <caps/> nonza. I
> > think there should be some consistency.  
> This will require some signaling from the client that it is able to
> parse those nonzas. Otherwise some clients might break if they
> suddenly receive unknown stanzas?
> But this signaling could be done with a caps feature? (The server does
> have the clients feature list anyway, right?)

Frankly, I don't know which way is better. I'm just against
semi-working solutions, because stale disco cache is bad and will lead
to bad UX: this will spawn "bug" reports like "hey, my xmpp client
doesn't see the feature my server is providing, but it works only when
I reconnect". So we either develop a solution or drop caps from
features at all.

I also think that disco cache is a bit more broad question, e.g. it
would be great to cache effectively features of services, rooms, etc.
The current approach as I understand is to use polling or disco
"pre-requests" which is PITA for client developers (most of them
actually ignore it).

More information about the Standards mailing list