> Oh yes. I tend to think that it should be *impossible* to have > collisions. Thats why I like appending a type to the end. That way there > are no two messages with the same ID, even if they are of a different > type.
Yes, I agree. > > > If we store different types in different tables and access them with > > different messages, then the chance of key collision stays the same as we > > increase the number of message types. > Ewww.. tables bad. Don't like 'em. The more homogenous the server is > the better, imho. Tables are good in this particular case because you need to divide the datastore into parts. The methods and datastructures generalize to more than just the CHK/SVK/KHK debate, but also to indexing. A Name is just another item you can insert. It goes in its own table like every other kind of key. However, it would actually have its own datastore since names should compete with actual data but with other names. Same with metadata attached to names, it should be in a dataspace separate from the normal data and be stored so that it can be indexed efficiently instead of the way we store data. You can use the same way of doing things as for CH/SV/KH keys. Each key type gets its own set of insert/request messages and it's own Key-subclassed object (ContentHashKey, NameKey, etc.) and its own table for holding entries. The key types carrying data will subclass from a common parent which sticks their data in the datastore while the key types carrying names/metadata will subclass from a common parent (if there end up being multiple types of metadata, which I doubt) that sticks the metadata and names into the namestore (just a datastore optimized for storing names and metadata instead of data). All the code for handling different key types is put in the message objects associated with the different key types. Adding a new type of message to be handled is as simple as installing a couple of new classes. Well, there's still some tweaking of the datastore necessary to add new key types on the fly, but we can do it and it won't be hard. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
