> > As I said, I want the code to be independant of how values are encoded in the > protocol. As long as I cannot tell at read time whether it is a numeric, > boolean, or string value I will have to use the current complicated FieldSet > using the interface. If I could tell at read time, then I could make the > FieldSet much easier, since it would have to be transport dependent. > > I don't see the thing with the "sibling subclasses" either. A FieldSet is a > set > of fields, these fields can contain among other things other sets. The fact > that the current transport represents this using a dot method is not > important. > > And I don't believe there is a need for a method that searches for a field in > all the subsets with a certain name. I can't see any use for such a method.
Hmm. I really, honesty, can't understand where you're coming from here. For one thing, a FieldSet can only contain fields, it cannot contain other FieldSets. We have no way to represent that in the protocol even if we had a need for it. Now when the time comes to fetch a value from these fields, you have to pass a field name: there may be one field with that name, or there may be multiple fields with different names that are each subclasses of that name, so the result of that fetch returns a set. The constraints in the spec should be sufficient to ensure that when you expect that set to have only one member, it should, and may throw an exception otherwise. FieldSet is already much more complicated than it should be--I'm suggesting that you simplify and encapsulate it by making it totally ignorant of the semantics or type of any field. Secondly, what the hell is a protocol for in the first place if it doesn't specify exactly how ALL necessary semantic information is encoded into a sequence of bytes? That's what it's for. A Transport method just determines how those bytes get from here to there, but which they are /must/ be determined by the protocol. You don't need to "tell" at read time what type any field is, because if you don't already know you shouldn't be fetching it. The protocol itself tells us what fields mean. If it doesn't, then they're just plain text. Maybe our confusion is that you want to be able to switch transport options in mid-stream, while I'm coming from the assumption that the transport has been decided on before the first byte is read of any particular message, and transport options within the message only affect things that happen after them. That's one of the purposes of handshakes--to be short and simple to set up options for further communications over the channel. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
