Perhaps is would be usefull to think in terms of a stack, and where each thing that happens to a message should occur in the stack. (or a chain of streams, if you will).
Rough example, Application (Java, C, Smalltalk, etc.) Message Protocol ( Currently text, could be binary ) Encryption Transport (TCP/IP, UDP, UUCP, etc.) Physical Layer (Wire, radio, etc.) The message format should be neutral, and not specific to either the application language or the transport. The trouble seems to be the interface between the message spec and the application, I don't see where the transport comes into this. Things like types are specific to a language, it's not even relevant in Smalltalk, you just bust up the message and you don't have to worry about types until you need to do an operation on a piece, then for example you would send an asInteger message to a piece and perform the operation on the result. Trying to have fields with variable 'types' in the message spec itself seems like a really dangerous road to go down, more like defining a database schema than a protocol. As an example, from a language independant viewpoint, I wouldn't care if the UniqueID was hex, decimal, or sanscrit, as long as its representation was unique, and unlikely to collide with another message. That's what's important to the message and protocol spec, the representation, not the underlying 'type'. David Schutt _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
