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. > > 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.
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. Right. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
