On Thu, 27 Apr 2000, Brandon wrote: <snip> > 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.
This is exactly what I have been trying to say. If you use subclassing of the Request message, which has to be used to implement Request with different behavior, to reflect what key is being used, which is really is just data carried by the message, then you end up with exactly the situation you describe. First you have your Data request messages; DataRequest.KHK DataRequest.dKHK DataRequest.CHK-SHA1 DataRequest.CHK-MD5 DataRequest.SVK-DSA DataRequest.SVK-RSA Then you want the InsertRequest messages, which is also a subtype of request, so you need to create another bunch of messages InsertRequest.KHK InsertRequest.dKHK InsertRequest.CHK-SHA1 InsertRequest.CHK-MD5 InsertRequest.SVK-DSA InsertRequest.SVK-RSA Then you want a Meta-data Request MetaDataRequest.KHK MetaDataRequest.dKHK MetaDataRequest.CHK-SHA1 MetaDataRequest.CHK-MD5 MetaDataRequest.SVK-DSA MetaDataRequest.SVK-RSA Then you want a FollowThrough request, FollowThroughRequest.KHK FollowThroughRequest.dKHK FolllowThroughRequest.SVK-DSA FollowThroughRequest.SVK-RSA and I am convinced that this is not all the different kinds of requests that might be necessary. And if you consider that the current node is written in Java, which means no multiple inheritance, trying to do this without moving the verification of the keytypes into other classes would mean LOADS of code duplication. It is a problem that always occurs if you try to use one name to name several independent things. Say I have an Ice Cream bar, and I sell Chocolate, Strawberry, and Vanilla Sundaes with Chocolate, Strawberry, and Nut toppings. I could either write a menu like: "Sundaes Chocolate with Chocolate Chocolate with Strawberry Chocolate with nut Strawberry with Chocolate Strawberry with Strawberry ... etc" and scare off my Customers or I could write: "Sundaes: Chocolate Strawberry Vanilla served with a choice of Chocolate, Strawberry, or Nut topping." > 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. 1) Having one way to add different new capabilities is not necessarily a good thing, because of the effect above. It also creates a major problem with inheritance. 2) Of course it can support an unlimited hierarchy. 3) But the situations are distinctly different, so it is no good to handle them the same. > 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 -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
