[Standards] Re: [jdev] XEP-0115: Entity Capabilities
stpeter at jabber.org
Tue Jul 3 16:02:38 UTC 2007
Rachel Blackman wrote:
>>> That said, I think we can come up with some simpler logic. If a given
>>> token is prefixed with 'h$', for instance, we know it's a hash and
>>> should be both validated against the result, and -- if it matches --
>>> cached globally instead of per-client. But for backwards compatibility,
>>> a disco on node#h$<hash> would still give you the proper results, and
>>> COULD be cached on a per-client basis.
>> Possible. But where does the token go? It seems preferable to define a
>> new attribute for this. Hmph.
> Let's say we have node='http://ceruleanstudios.com/astra/caps' and
> ver='h$someverylongstring' and ext='h$otherverylongstring'
> Why can't something like...
> http://ceruleanstudios.com/astra/caps#h$someverylongstring work just
> like an old ver='126.96.36.199' would generate an
> http://ceruleanstudios.com/astra/caps#188.8.131.52 would under the old
> system, for an old client? After all, you still have to query the hash
> to get the features represented, which you then hash to validate and --
> if it's valid -- store it globally so that /all/ clients which have
> 'h$someverylongstring' have that featureset.
Hmm, OK. On that model, what is the use of 'ext'? Do you put a hash of
all the "base" features in 'ver' and a hash of all the "extended"
features in 'ext'? That seems potentially sub-optimal, because different
clients might divide "base" and "extended" differently, which means
you'll need to send and receive a lot more disco queries. It seems
better to me if we have only one hash for all the features.
> Thus, old clients can use it just fine with old-style logic. Only the
> new client needs to know that h$ means 'take everything after that $,
> and treat it as a hash;' old clients can still query seamlessly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards