On Sun, 07 May 2000, Brandon wrote: > > 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 :-(. > > Well, I wouldn't call it merging hell. I just modified setField() and > writeMessage(). It's easy to back out my changes if you don't like > them. I thought I had said I was going to implement dotted fields. I > didn't mean to step on anyone's toes.
No problem, it is nothing unsalvagable. The approaches were slightly different, as I was reading the dotted fields when someone tried to access the subset rather then when creating the set, but I think your approach might be better. I have to sleep now though, I have been coding since 9 this morning. I'll be up again to finish off in about five and a half. > > I also notice that you did not change the place where dotted fields were > > already being used, in the DataSend method. > > You mean for Storable? Yes, I forgot to change that. I'd do it now, but I > don't want to interfere with your changes. I'll get it. It is actually a little complicated since the DataProperties class can't handle subsets. I will probably just let any dots go in there for now, though later this should be fieldset class itself. > > 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. > > Alrighty then. When will this be committed? I need dotted fields in order > to make the changes to support metadata. As soon as I get it working. What metadata do you need to implement? The storable fields ARE the metadata, any other metadata should be in the trailing, not in the message, like we decided. > > 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. > > Yes, it's very sensible. I just thought it was decided to go with > EndMessage instead of DataLength=0. I could very well be wrong. It's the same thing really. EndMessage is still being used, just it isn't the only way to end a message with no trailing field. > I think that we should primarily work on a single protocol, but I think we > should allow for multiple protocols to be used. It shouldn't be that > hard. I'd make the necessary changes, but we need multiple protocols > before I can do that. It would be very useful to support multiple > protocols, particularly for gateways. For instance, I don't need > encryption for the communication between the nodes on my LAN, but the node > I talk to on the Internet might only speak to node with encryption or it > might only talk over an SSL connection in order to be clandestine. I > certainly wouldn't want to have to make my entire local Freenet network > use SSL connections just to talk to this one node. Nodes need to be able to talk to one another. We should not have it so they can't. > Besides, Ian keeps asking for backwards compatibility with the old nodes > and this would elegantly solve this problem. The deal with releasing code so early was that we would break compability several times. We will cripple ourselves if we don't accept this, regardless of how much effort we spend complicating things in the name of backwards compatibility. I think we should spend more effort on forwards compatibility for the versions of the protocol that will actually be used. > > > > _______________________________________________ > 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
