> Becuase our needs will change. I really doubt that we won't come up with > some new cool thing we can do to SSKs. Overloading the SSK syntax is quite > frankly a nieve thing to do in the long run.
Your system should be as complicated as it needs to be to meet your known needs. You can't realistically design for things you haven't thought of yet. Doing so leads to systems which are so overgeneralized as to be difficult and unpleasant to actually use. DBRs are a fundamental thing for Freenet publishing, not a nifty but unnecessary feature like splitfiles. So it's okay to merge them into the key. Everything else can still go in metadata like before. The difference between fundamental and nifty features is that fundamental features are added slowly and have to be supported by everyone. So it's okay to do things like change the URI syntax to include them. How often do they come up? In 3 years we've come up with 4 fundamental things: names, signatures, content hashes, and date-based indexing. New fundamental things are going to be added slowly enough and will be important enough that we should add new key types for them. We do, after all, have an expandable key type system for this reason. In the particular case of DBRs, they are only reasonably used with SSKs, so it makes sense to merge them into the SSK URI format. If this were not the case then the reasonable thing would be to either expand the overall URI format (if it was a really pervasive and fundamental thing, such as with docnames) or to add a new key type (such as with SSKs). For not so fundamental things, such as splitfiles, the appropriate thing is to define a new metadata message and put such information in a control document. URIs need to be kept simple. _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
