> My solution to the problem of storing the key types with the keys > is to store the different types of keys in different tables. So > Request.Data looks in the KHK table, Request.Data.ContentHash looks > in the CHK table (or generates it if the node doesn`t bother to > precalculate CHKs for some reason, like no one in that node cluster > uses them) and so on. No problems with key collisions.
No, Oskar's right that it's much better for the network if "closeness" compares all keys, but only returns "equal" if types match: that gives us the best clustering and still only fetches the right Documents. Key collisions are not a problem if KeyType is part of the key. I really don't think this is tricky at all, but then I haven't tried to actually do the code yet. :) Another good reason not to muck with message types is that it makes it easier to insert documents under more than one KeyType by just putting both keys in the header of Send.Insert (DataInsert). But that is a real change in the data store's behavior in that it may have to detach them at some point (for example, when the SVK is updated the old document and CHK are still valid), so that can wait until we're sure we want to go there. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
