Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul wrote:
Joe Hildebrand wrote:
On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:
Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Forgot to add, change name from ver & ext to verh and exth ?
Why?
Conflict with existing clients - too many of them in the wild dont use
these semantics.
Others have already responded to this, but just to reinforce, I *did*
talk about backward compatibility. Existing clients would continue to
work just fine. New clients just have to be able to detect other new
clients, to know if they are supposed to be able to check the hash.
Presumably, new clients could choose by policy to ignore un-hashed caps
from old clients.
Not sure if anyone addressed the actual I was thinking of (need to read
rest of thread).
Essentially, how would 'new' clients know is something exhibited in ver
or ext is hash or 'old' value ? Aren't those identifiers not expected to
be opaque (though consistent) ?
Considering an ext of "my_ext 1233ab" and "#hash1 #hash2" exhibited by
two clients - how would the reciever know what is hashed as per 'new'
idea and what is 'old' ver/ext ?
As I understand the proposal, there would not be "#hash1 #hash2" -- why
do you need multiple values here? You concatenate all the supported
namespaces according to some rule and then hash the whole thing. So
there's only one hash. But that means something different from 'ext' or
'node' or 'ver' so I think it needs to go in its own attribute.
/psa
What Joe Hildebrand proposed initially had hashes for node & ext's - I
was refering to that here.
The approach has the advantage that, clients can query and validate (and
so independently cache) namespace#node_hash, namespace#ext1_hash, etc -
and so having multiple hash'es allows reuse of cap's info across clients
and allows them to modify ext's each independent of the others.
Addition or removal of a plugin will not result in the entire hash being
invalidated - just a specific hash will be removed, or modified.
A single hash has the drawback that it will either protect the entire
set, or none at all - and so effectively we lose ability of separating
node's from ext's since we cannot independently validate each.
Which is why my initial query was if this should be 'verh' and 'exth' to
indicate hash'es and not 'ver' & 'ext' for the data itself (because of
new clients rejecting caps from old clients) - and 'new' clients would
query for these instead of ver/ext. I am sure there would be better
ideas to tackle this problem.
Though cache pollution looks like a serious issue (especially server
cache for pep case), I am wondering if we are not taking this way too
seriously - I did not see so much discussion for esessions ;-)
Regards,
Mridul
s/node/ver/g
Apologies.
Mridul
