[vos-d] s5 concurrency (design part 2)

[Peter Amstutz]

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  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[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 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070412/47c0342a/attachment.pgp