On Mon, 24 Apr 2000, Brandon wrote: > > But there is no reason to have different tables (yes I have read your later > > posts, and you make no sense), and it hurts the efficiency of the routing > > greatly. > > It doesn't have anything to do with routing at all. Routing is identical > for all key types. Storing them in different tables is merely storage and > lookup. In no way does it hurt the efficiency of routing. > > I think the difference is where the code branches. Having the key type in > the key means that there is a single module/class for all key types and > the code branches inside the pReceived() method for different key types.
No, I don't want a single class for all key types. I want it to be like it is currently for Addresses - the protocol (which is the type of address) is contained in the address value (tcp/127.0.0.1:10001), and that is what makes it possible to have a different class for each type of address. > I think that differences in behaviour should be, as much as possible, > defined by the message type instead of the fields inside the message. So > there should be a separate module/class for each key type. This might seem > like more and redundant code, but with proper inheritance it won't be. I am fine with a new message type for a new key type. Note: "a new message type". Only one new message, a subclass of DataSend is needed. There is absolutely no reason to change the Request message, because when the key will only match data of the right type, so the node that finds the data knows what kind of DataSend to return from the key. 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.... > So, instead of upgrading your Request objects when new key types > are created, you could leave the current objects as they are and install > new handlers for the new key types. Then you can easily determine what key > types you want to allow support. Why would one have the upgrade the Request object when it does the exact same thing? Who said anything about upgrading anything? > _______________________________________________ > 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
