On 2014-06-23 15:03, Evgeny Khramtsov 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.
Prosody for one doesn't actually cache caps. Our PEP module caches a set of nodes of interest, but not the full caps. We've been considering implementing full caching of disco#info/caps, would be interesting to have the server reply to disco#info queries with cached data. And Jabber/XMPP was designed as a thin client - fat server system. So there will be lots of state on the server. >>> 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. When does this happen? Other clients should check with disco#info and caps if the client supports things before sending them. > 2) We route shitload of presences to a client. On and on this goes. Presence de-duplication would be very interesting to implement. As in, only route presence that differs from the previous one. -- Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
