Hi Christian, Thanks again for your input. Comments inline.
On Dienstag, 13. Februar 2018 23:20:54 CET Christian Schudt wrote: > Hi Jonas, > > > You are referring to the processing entities side? The entity is free to > > choose from the set as it desires. The order of elements inside the hash > > set is undefined. It could for example iterate a list of hash functions > > in descending order of preference and look for hashes in the hash set. It > > could also first check if any of the hashes is in the cache and prefer > > that. > > > > I see this could be clarified, but I’m hesitant to make a normative > > statement on the behaviour. Some suggestions can be put into the XEP > > though. Do you see a reason to make this normative? > > See, you made a good point here: First check if any of the hashes is in the > cache. I forgot about it in my implementation and that’s why I think it > could be beneficial to have something defined in the specification. > > Think about the same capabilities sent by two different entities, but with a > different hash order each. <c> > <hash algo=„sha-1“>abc</hash> > <hash algo=„sha-256“>def</hash> > </c> > > <c> > <hash algo=„sha-256“>def</hash> > <hash algo=„sha-1“>abc</hash> > </c> > > If an implementation would just pick the first hash each time it processes a > presence with Caps, it will likely end up with two service discovery > requests and two hashes in the cache, although one would be enough. I honestly didn’t think about that, since my implementation does ignore the order between the hash elements and simply tries them in the order of the local hash function preference. I’ll include a few implementation notes on this topic in the XEP, thank you very much. > The spec should recommend to first iterate over all hashes and check for > each hash, if it’s already known (cached). > > I *think* I outlined the integration with XEP-0115 in the XEP already. Can > > you be more specific on where you would like guidance? > > You write (or I understand): If there are also `115 Caps, you may use them > to get the disco#info from the cache. In the next sentence: you must not > use data from the 115 cache, if there are also 390 Caps in the presence. > *confusing*? I assume you’re referring to §7.2, Upgrading from XEP-0115. I think you missed the "without verification" qualifier in the last sentence which should make things clearer: *if* a XEP-0115 cache is available and *no* XEP-0390 caps hashes are received, an entity MAY choose to still optimize the query by falling back to the XEP-0115 behaviour. However, if XEP-0390 caps hashes ARE available, the entity MUST use them to verify the data obtained from a XEP-0115 cache (if they have no XEP-0390 match and went down the fallback route). I think a rewording will make this much clearer. > Generally I thought about some guidance about what I’ve worked out during my > implementation: Some ideas about a common interface and some business rules > for processing both Caps Extensions in the same presence. I’m not sure if the XEP is the right place for that, honestly. I’d like to restrict it to describe protocol, not to implementation details which are solely in the realm of the Software Engineering side of things (which is in contrast to the things we discussed above, about the Cache implementation). > In the same sense > how XEP0191 describes the relation to XEP0016 and recommends to use the > same backend storage and defines a clear mapping [1]. But this is behaviour which is visible to other entities. A client might implement XEP-0016 *and* XEP-0191, or one client may implement XEP-0191 and one client may implement XEP-0016 and to gain some meaningful interoperation between the two approaches it is kinda needed. It is not visible to other entities if you use a common interface for your XEP-0115 and XEP-0390 implementations or not. We can of course make a huge section of implementation suggestions, but I don’t think this is the right place to do that. > Maybe also some words about if XEP0115 cache can be mixed with XEP0390 > cache. In my implementation I use the same cache for both. > Maybe you also have some recommendations what to use as cache keys. > In my implementation I currently use something like: „sha1(XEP# + algo + > bas64(hash)). Not sure if it’s good. I’m using the disco#info @node values (Capability Hash Node in XEP-0390 terminology) as cache keys for the (caps -> disco#info) cache. They are different and already include the hash function and hash, and there’s no need to run SHA1 on top of that. thanks and kind regards, Jonas [1]: https://github.com/xnyhps/capsdb/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
