On Thu, Apr 12, 2007 at 08:16:59AM -0400, Reed Hedges wrote: > > So messages between local objects will be serialized and passed like > remote messages, rather than being method calls? Is that overhead a > concern?
It is a concern, although I'm don't think I would call it "serialization" since there is no data conversion happening, it is just copying the method parameters into a temporary message structure, possibly copying the message if it needs to be queued, and then copying those parameters out of the message structure onto the stack when we get around to actually calling the method. > If so, maybe an optimization would be to have a message format that just > packs native machine format arguments into the message in the same order > as the method handler arguments (omitting the field labels)? At the moment it does still include the field labels, but the labels are just pointers into the string table, so they are cheap to copy as well. I think it is important to retain the field labels and data types, because once the message is constructed we don't know if it is going to stay in process, be passed to a scripting VM or be sent out over a socket. On that note, one of the things I want to do is come up with a set of rules for what to do when an incoming message has slightly different parameters from the method signature of the target. This allows looser coupling between components and accomodates minor version changes, which will mean a lot when there are multiple versions and multiple implementations in the wild. This also gives developers guidelines for what is considered a backwards compatible change, and generally follows the principal "be strict in what you emit, and liberal in what you accept." The rules I'm thinking of would be along the lines of: - "If the message has an unrecognized field tag, but all other fields can be matched, ignore the unrecognized field" - "If the message fields are in a different order than the method expects, reorder the message fields to match the method fields." - "If a field datatype should be string, but the message provided an int, convert to the ASCII form for a decimal integer." - "If a field is missing and has been marked as optional, provide a default value" - "If a field datatype should be floating point, but the message provided a string, convert to a float if and only if the string contains an floating point value in ASCII form" And so on (these are just examples off the top of my head). Message calls that can't be converted in this way get rejected. The idea is that these are common sense conversion rules, and that by specifically listing what a conforming implementation should accept allows some slack between the sender and receiver to account for version mismatch, minor errors and general laziness of users (as well as permitting string/ASCII encodings to be used in most cases even if the real datatype is an number.) All the primitive datatypes will have two type encodings specified, a binary encoding and a normalized ASCII encoding. The XML schema datatypes spec would probably be a reasonble place to start for text encodings. Thoughts? -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list [EMAIL PROTECTED] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
