> > No, you'd have generic code that handles the parsing and unstanding of > > your type file. Adding new types is simply a matter of adding a new entry > > to that file. > Exactly... Types aren't supposed to change. Having new types means > breaking old programs. You're going way overboard here.
If we make new types now, stuff will break. At least with this we can upgrade the node's protocol support by adding a new protocol definition. Dont get me wrong here: the protocol isn't supposed to change often. But this eases backwards and forwards compatibility. Older nodes may not be able to make full use of the new tags/types, but at least they can understand them to a degree. Another side effect is you could trivially write a program that can verify if a message is protocol X compliant. > > Doing it this way makes it more general. You could put in rules for > > comparisions of generalized types. > <shudder> > > > ie record 1 is older than record 2 if record1's date is > record2's date > > or record1's date = record2's date and record1's time > record2's time. > > And you can't do this with integers? You can do it with integers if you know already what format the records are going to be in. This way the program only knows that they can be compared and there are rules do do so. It doesn't concern itself with the rules since they're handled by the parser. -Larry _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
