• CoreProtocolEnhancements

Just some stuff I've been musing about (much much more is planned for S5, see the mailing list archive or posted S5 plan documents on website):

• String to unique integer mapping. Send "this string is id X" and then have a new message format that uses the string map for to/from fields and message field keys. Will shave some overhead off messages (since a lot of header information will be shaved down to 4 bytes)
• Transactions/remote locking of Vobjects (use a message block to send a transaction)
• <strike>Eliminate old XMLish message syntax, only use binary format (this is almost certainly going to happen)</strike> (This has happened)
• eliminate hostnames from anything VOS actually sends, use only numeric IPs to avoid all the host aliasing crap

  • do we really want to do this? What about human-readability and DNS round robin load balancing; most importantly, storing references by IP address breaks completely if the IP address for a host changes -ReedHedges

• Not really a core enhancement, but "CGI for VOS": adding a metaobject which, upon receiving a message, would fork()/exec() another program, and pass the VOS message to the child process. The "CGI" child process would echo the reply message(s) to stdout. If we emulated the actual CGI standard, we might even be able to leveraege existing programs, although there's the question of what do you do with the output (which is HTML) . It could be added as CGI support to HyperVOS of course, but that's a little different. The idea is to be able to write extensions to Vobjects without touching a line of VOS code in the server.

Of course, there's getting the Python stuff up and going too, so complete server extensions can be written in Python.

Listeners

• Order listeners. Well, mainly have flags that force a listener to be at the beginning or end, while normally they are just added in the middle. (E.g. apache module callbacks are either at START, END or MIDDLE)
• Abilitly for a listener to cancel invocation of later listeners
• Ability to group and buffer listened-to things; also needs ability to group actions that produce notifications. For example, select a group of objects to listen to. If any of them change within a small amount of time, listener gets one notification message that contains all the changes rather than several independent notifications. This buffering can be done on the remote side or on the local side using an intermediate listener. Or, instead of buffering over time, include in the libvos API a way of signalling the beginning and end of a series of changes to an object group, so it can only send notifications when the end of the group change is signaled. Another variant of this that also might work, is to listen to a subtree of objects or properties; on any change to any member of the tree, a notification is sent that includes the changed state of the whole subtree in a COD (like a search).

  • -> This should be done transparently by VOS as you add/remove listeners on individual objects.

• Attach conditions with remote listener additions, e.g. on types, contextual names, property datatypes, etc. This basically offloads some work from the client to the server.