> The other messages have _NO_ difference in behavior - so it is not a matter of > whether difference in behavior should go in a field or in a message type or on > an all expenses paid trip to Hawaii. What key type it has is simply data it > passes to tell the returning message what kind of DataSend should be used - > and > if you want all the data that a message passes to be in the message type then > that will make for an interesting protocol....
Requesting KHKs, CHKs, and SVKs don't have any difference in behaviour on a request, but I'm thinking about even more heterogenous messages. For instance, if we implemented the ideas that have been tossed around about storing metadata separate from the data, under its own key, I don't think that metadata should be stored exactly the same as data. I think that metadata should compete with metadata and data should compete with data. So the two should be stored in different stores. Looking for them in different stores requires different behaviour in the request. And then there is the idea of out-of-band data where the request class doesn't look in the store, but fetches a web page or something similar. These are instances where a new message should be created. We could add key types for such things and make key handler objects or we could just make new subclasses of the normal messages to handle special new behaviour. If we're going to do that, I think we should make all key types, even the very similar ones, be handled by their own message types. > Why would one have the upgrade the Request object when it does the exact same > thing? Who said anything about upgrading anything? Assuming that the key type means something to the node and not just the client, you will eventually find that there are new types of keys that your node can't handle and that you'd like to be able to handle. At this point you must upgrade/install some classes. If the behaviour is different for requesting different key types, you have to either upgrade your request class or install some new request subclasses, depending on how key types are handled. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
