Difference between revisions of "Disco caching notes"

From XMPP WIKI
Jump to navigation Jump to search
(Created page with "Daniel: before sending first message, need to look through disco items. Costs at least one unnesssary roundtrip, to do disco#items and then feature request for each item. Ide...")
 
(Blanked the page)
 
Line 1: Line 1:
Daniel: before sending first message, need to look through disco items. Costs at least one unnesssary roundtrip, to do disco#items and then feature request for each item.


Idea: Have data form which
Kev: why can't you send a message without doing disco query.
Daniel:
* e.g. want to send image, then need to know which XEPs are supported.
* e.g. figuring out whether external components (like for stickers) are available
Sam: Querying a MUC, the items change every time.
Daniel: concerned mostly about server items being cached.
Disco extension form that contains hashes of cached values, as part of CAPS.
Disco items query, jid/name/type. Idea is to create form, variables names are the jids, then has two values. 1st value is name, 2nd is type.
Use hash or inject data directly?
Dave: rather try and make this generic than not.
Ralph: Usecase that I was talking about. Separates out MAM as separate component from server for scalability reasons. First thing you want to do when connecting to server is to discover where that MAM component lives.
Kev: if you want your MAM not to be hosted on the server directly, we already have a mechanism for saying : let this component ..
Link Mauve: Salut a Toi and Moving using disco for microblogging and pubsub stuff. So an argument towards being generic.
Sam: independent of path... showing items or hash... did (recently deferred) XEP for HipChat (general topic is lists, Entity Versioning: 0366)... this was the problem we tried to solve as well.
Idea was that you query a list once, in future you only get the diff.
Daniel: Remember that, but it was only traffic minimization and not roundtrip minimization.
Sam: think it would work for either case as the hashing and diffing mechanism.
Kev: define a form that we can put in disco#info, could write a ProtoXEP for that.
Daniel offers to write the ProtoXEP.
Kev: nice thing about putting a form into disco#info is that it gets bound into the CAPS hash. If we serve the CAPS hash as part of XMPP2, that means you can avoid roundtrips.
Daniel: when you put the items in the form (instead of hash), means you don't have to do the disco#items query.
Kev: still issue when having lots of items.
Daniel: maybe we can come up with a solution for feature hashes?
Kev: The more we put in, the more complete we make it, the more often we invalidate the hash. We can put the hash of the disco#info into the hash of the disco#items, that go into the disco#info query.
A. Server has to query these things B. Means you have to go recursively through to each item. C. Top-level hash would change often.
Matt: Approach seems sound. Some entity would eventually ask not to be cached, or could decide how deep to recursively hash.
Daniel, Kev: As a client you'd have to query to leaves of tree, which is not desired.
Kev: By not bothering to require recursiveness, makes implementation simpler.
Daniel: let's do the disco#items hashing first, and leave disco#features (and recursive hashing) until we know whether this is required or not.

Latest revision as of 21:34, 3 February 2018

Retrieved from "https://wiki.xmpp.org/web/index.php?title=Disco_caching_notes&oldid=9984"