> Hi there Brandon, > I recieved your last couple of conversation snipits regarding keys and > sub classing. I obviously haven't got the whole picture (as I only joined > this morning) but I'm a main frame AP working with database > design/implementation on several platforms so thought I'd say hi. If you > want any input please feel free to ask or alternatively can you send me the > initial points of your argument along with the problem so that I may have a > look (morbid curiousity).
Hi! Actually I just gave in to the crazy people that want key type handler objects. But if you're interested in the debate I'll summarize it for you. If you're not, you can just ignore the next paragraph. :-) The question was how to implement the handling of different keys. We already have a message type subclassing implementation where you can specify a message to be Request or Request.Data or Request.Data.ContentHash, etc.. If the handlers for Request.Data can't be found, it will use the one for Request, and so on. The question was how to you make a Request that is specifically for a ContentHash key or a Signed key. I was saying make a new subclass Request.Data.ContentHash. The other people were saying add a field to the message saying KeyType=ContentHash and then use the normal Request.Data. Their arguement was that you might want to subclass Request.Data in some other way and still specifiy that it is ContentHash, Signed, etc.. My arguement was that the only reason you'd ever want to subclass Request.Data is to make it handle a specific key type. Since we have message type subclassing, we should use it. It adds the benefit that if you want your node to do something new, anything new, you add a new message handler for a subclass of a message. Otherwise you add a message handler for some things and a key type handler for other things and why bother? I gave up because although they can't think of a reason you'd subclass a message except to make it handle a specific key type, they think you might want to sometime. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
