> > Thing 3: We need to come to an agreement on the partial message format so > > that I can implement it. I've been sketching out a proposal -- here's the > > current > > draft: > > I agree. But This is a client issue, so it depends on the format of the client > meta-data (that which resides inside the Trailing field) which nobody has been > able to come to any conclusions about how to format.
My proposal seems to be tentatively accepted, or at least not strongly disagreed with, which is to have field-formatted data. The things we need to agree on are what fields to use for multipart metadata and how putting the data in the trailing field should be handled now that there is metadata too. I'm in favor of a trailing field inside the trailing field to specify the start of the data. I know this sounds crazy, but the reason is that we could implement a very flexible, simple message parser. When it hit the trailing field, it would check the encryption type (except on EndMessage) and then pause from reading the stream, decrypt the encrypted portion of the stream, and then continue reading the stream just as before. The parser will not need to know anything about encryption or any new formatting conventions. It just needs a hook to call a decoder when it gets to a trailing field and when the EncryptionType (or whatever) has been set. This method would also allow for multiple layered encodings because each encoded trailing field can contain an encoding type and trailing field. I don't know if this would be useful, but flexibility like this is the sign of a nice, flexible system. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
