[Standards] Re: [jdev] XEP-0115: Entity Capabilities
rcb at ceruleanstudios.com
Tue Jul 3 03:48:22 UTC 2007
>> That said, I think we can come up with some simpler logic. If a
>> 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
>> 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.
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.
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards