On Sun, 07 May 2000, Brandon wrote: > Sorry I haven't been on the list for the last few days. My account has > been buggy. I missed a lot of discussion as there was just too much to > read if I don't keep up every day. > > Anyway, I just committed dotted fields. You can read and write them. One > quirky is that if you do a=b and then a.c=d, the original a=b is > lost. This is because a field can only have either a single value or an > array of multiple values. This is mainly because I couldn't decide where > to put the original single value. The object stored is either a string or > a hashtable. If there is a desire to be able to have both then I can make > every value a pair of an optional string and an optional hashtable. I > wasn't sure if this was necessary or desirble.
It would have been a lot easier if you had held back on that seeing as I warned that I was going to be working on major changes to the RawMessage. You put me in merging hell now :-(. I also notice that you did not change the place where dotted fields were already being used, in the DataSend method. As part of the pluggable transport interface I had already added objects that are FieldSets, which can contain fields with String, numeric, boolean of FieldSet values. I was already using the dotted fields to do this. > Also, I can't run the client because of a ClassNotFound error on > SymmetricCipherConnection. It's a very bizarre error as I can't seem to > find where it is actually be thrown from. Why is this and when will it be > fixed? > > Also, why are messages ending with DataLength=0? The last thing I > understood was that we had decided to end them with EndMessage. I did not make this change (if it changed) but it strikes me as pretty logical to end after the trailing field name if the DataLength is zero (or not existant). It makes more sense then looking for an arbitrary name. > Also, I think that we should split the address syntax into two parts. This > would allow for backwards compatibility with old nodes and forwards > compatibility with future nodes. > > The two parts are transport protocol and message protocol (or whatever > you'd like to call them). So we can have fps:tcp/blah, tcp/blah, > fps:udp/blah, udp/blah. fps in this example is the secure freenet protocol > in which there is cipher/key negotiation. Lacking a message protocol, it > will assume a straight stream of freenet messages. So old addresses will > work as before both in old and new nodes. New nodes will specify addresses > to each other with fps:tcp and to old nodes with tcp. > > This will also be useful in the future when we implement a motley > assortment of message protocols such as SSL, SMTP, etc.. Nodes that > understand a particular message encoding protocol can talk to each other > and will know whether or not they can talk to other nodes by whether or > not they have the appropriate classes to handle the type of address. I think we should try to stick to using one protocol. It is headache enough trying to get the code to support more then one at all, more then one at a time would be really bad (though it could be written to, the node does not currently support more then one network protocol (ie tcp, udp) at a time either). > _______________________________________________ > 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
