On 23 June 2014 14:03, Evgeny Khramtsov <xramt...@gmail.com> wrote: > Mon, 23 Jun 2014 12:11:35 +0100 > Dave Cridland <d...@cridland.net> wrote: > > > On 23 June 2014 11:44, Evgeny Khramtsov <xramt...@gmail.com> wrote: > > > > > 1) servers hold too much state > > > > > > > What state do you think they hold that they should not? > > CAPs cache for example. > > Oh. I wouldn't classify that as state, so I'm glad I asked what you meant.
I think keeping a Caps cache around is OK, though, not least because you can use it for servicing disco requests much faster (and without bothering local clients), but also the levels of optimizations and interop stuff one can do with one are quite high. Admittedly, many of these are most useful for local clients, but remote client caps, too, have their uses. > > > 2) clients receive too much data > > > > > > > By "too much data", do you mean irrelevant data or redundant data, or > > something else? > > 1) It's quite pointless to route a stanza with feature X to a client if > a client doesn't support this feature X. > OK. There's an implication there that you think this is happening; I've not generally seen this. Can you give concrete examples? Incidentally, if this *is* happening, then one way to solve it is with your caps cache. > 2) We route shitload of presences to a client. On and on this goes. > We do. We're a presence protocol though, so this goes with the territory. Do you think that we're routing redundant presence information to clients, or irrelevant presence information to clients? ie, do you think clients don't care about status/show updates, or do you think they're getting presence stanzas which contain the same state information as the previous received? Dave.
