[Standards] Re: [jdev] XEP-0115: Entity Capabilities

[Rachel Blackman]

>> 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.

Why?

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='4.0.0.47' would generate an http:// 
ceruleanstudios.com/astra/caps#4.0.0.47 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/