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 <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
