> No, the Request is still the same. You will need to add new code: but the code > does not change the Request class, it adds a new key class, and possibly a new > DataSend class.
Pluggable key handlers is certainly a way to do it although everything I said about keeping different key types in separate tables and such still holds, it would just be handled by the key handler instead of the message handler. I think it would be better handler by the message handler for reasons of consistency, but I'll get to that later. > Here is how I would want different KeyTypes to work: > > When a Request comes in, the key is read and it's type is determined. The type > is either known, or unknown. In each case the Node would: > > a) Known keytype > > - Create a Key object of the correct type. And this can of course be handled by either creating pluggable key types or subclassing Request and overriding the method that creates the Key object and what we're disagreeing over is which way is better. (Just in case anyone came in the the discussion late.) > b) Unknown keytype > > - Create a new Key object of the Key subclass UnkownKeytype. Save it in the > Message Memory, and route the request by finding the closest key in the > message > memory. Which is what Request does now. Unknown key types can be handled easily by making making for new key types subclasses of Request. That way unknown key types mean unknown messages and they will be handled by the fallback message type. > If we do it like this, adding a new keytype would simply be adding a new key > subclass for that type containing a verifyData method. No messing with the > message classes (since they are doing the same thing anyways), and no changing > code. Well, there is certainly some changing of code. The only question is should we subclass a message and override a method or have the default Request method for handling keys load a key handler class determined by the key's type and pass it off to that. > But a new Request class, when it doesn't even deal with the data, is just > insane. > > That said, I am of course not against the Introduction of new Request type > messages. I absolutely think that when a request that is supposed to do > something behaviorly different, such as only return Meta-data or whatever (the > optional follow-through requests for updatable data are an example), that it > should be a subclass of the normal Request, and that nodes that re not aware > of the new subclass should be able to fall back and just route it like a > normal > Request. But new KeyType != new Request behavior, the keytype is simply > information that the Request carries for the sake of the nodes knowing what to > do when they return the data. And here is really the crux of our disagreement. If you have separate key handlers then indeed there is no reason to make a new request class since all it will do is call a specified key handler. I'd rather take the functionality you want to put in key handlers and put it in a couple of overridable methods in the request class. If we're going to be subclasses messages for some key types (Metadata, for example) then we might as well subclass for all different key types. Otherwise you sometimes have to install a key handler and sometimes have to install a message (to support a new key type). Also, I don't see that key handlers do enough to be their own objects. They only have a few methods: store, retrieve, and verify. Storage and retrieval go quite well in the appropriate message classes for inserting and requesting. Verify perhaps should justifiably be part of a key handler object. I consider storage and retrieval to part of the message classes. That said (and I still prefer message subclassing to key handler objects), I would not be too terribly opposed to key handler objects as long as they were loaded like message classes are so that they are pluggable. There would have to be a KeyType field which contained the key type and the appropriate key type could be loaded from Freenet.keyhandlers.keytype or something similar. It is quite possible that I'm overlooking some benefits of splitting off keytype handling into its own abstracted layer. If, for instance, there was a that Requests might be subclassed other than to handle different key types, then it would be sensible. We'd want to avoid Request.X.ContentHash, Request.Y.ContentHash, Request.X.Signed, Request.Y.Signed. I can't think of reasons to subclass except to handle different key types, however. The beauty of using just message subclassing is that 1) There is a standard way for adding any capability to a node, being it handling signed data, searching, or a Usenet gateway, 2) the message subclassing supports and unlimited hierarchy (are we going to allow subclassed keytypes?), 3) Unknown Keytypes are treated just like unknown messages with fallbacks already implemented. I don't see any reason to treat unknown keytypes differently than unknown message types, although if there is such a reason then it is certainly a case for key handler classes. But while I'd like one layer, 2 layers isn't so bad as long as they work in a similar pluggable fashion. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
