On Sun, 07 May 2000, Bill Trost wrote: > The UniqueID is a value. It has always been a value. > > I don't find the term "value" to be particularly discriminating. I take > it you mean "number."
Numeric value. > In any event, as far as the on-the-wire protocol is concerned, all > values, numeric or otherwise, are transmitted as a sequence of ASCII > characters. That the protocol participants may be constrained to > intepret these sequences of characters as a hexidecimal constant or a > Freenet address is a higher-level issue, but the protocol still requires > them to be ASCII strings. If nodes are free to use different ASCII > strings with the same higher-level interpretation (for example, but > omitting leading zeros off of a hexadecimal representation of a number), > that's fine too, I suppose, but it certainly seems to confound the issue > to little obvious benefit. How the current protocol transports the values is beside the point. The point is that we currently have 3 kinds of field data: numeric, string, and boolean. Having the UniqueID be a numeric value makes just as much sense as having it be a string (personally I think it makes more sense, but that is only my opinion). But previously it has been treated as a numeric value by everything except Liberators fallback random code. The node has always treated it like a numeric value, it uses a long internally, and Long.toHexString (which produces between 1-16 chars). LIberator is just stupid about it, considering it will cut off the first zero itself if you generate the id from /dev/urandom. It is my fault, I'm sorry. Having it be numeric does not generally make it more complicated anyways. The easiest way to produce the ID is by reading bytes from source of random values. If you mandate that it be full length you will have to fill in a zero if the byte->hex conversin returned only one char. If you want to treat it numeric you will have to skip the first byte if it is zero. Big difference. > I guess I am proposing, as a compromise, that nodes should always send > the leading zeros. I'd rather the node didn't change the client's > representation at all, but the middle ground between arbitrary strings > and hexdecimal representations seems to fixed-length hex strings. There is no reason for a middle ground. Either we have numeric or string values. > What exactly are the arguments against using hex? It is easier and > faster to convert, and more compact. I didn't see any arguments > against it, which is why I assumed no one would care. > > It's a gratuitious change that breaks existing clients without > substantially improving how the software operates (Freenet is largely > bound by network latency, so intra-packet efficiency should have a > negligible effect). It doesn't break anything since all the clients will break when encryption is added anyways. > Remember, there are probably about half a dozen Freenet clients > available or being written, and changing a field's interpretation impact > *all* of them. Of those half a dozen at least three depend on the Freenet message class anyways. The fourth is Liberator which is my own. The fifth is FCRC which just needs to cut and paste from Liberator, and the fifth is an extremely incomplete c client. And again, this going into the main CVS, not the release branch. The protocol of the main CVS will have to change from the 0.2 release if we are going to make anything out of this. Freenet is not finished. I REFUSE to accept that we should even hesitate to make changes to the protocol because people are writing clients. They have been warned. > And you are still wrong about the UniqueID. You may think it should > be a string, but making it so is no less a change of the protocol > then making numerical fields hex rather then decimal. > > I'm not sure I agree there. Treating a UniqueID as a string means *not* > interpreting the field; changing numeric fields to hex means changing > one common interpretation for another one. Deciding to treat it as something other then a numeric value breaks all the previous nodes, all the java clients. But it does fix my sloppy code in Liberator. > > _______________________________________________ > 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
