Re: Designing a more efficient protocol

While i only understand half of it all, i figured while on the subject 
i'de ask something. I havent tried too much with pico programming yet, 
so bare with me for a second and let me know if im missing something. 
You mension how inefficient the current protocol is with each request 
requireing a response. What could always be useful is maybe a batch 
command, you give it an array of things to do, dunno, like all in one 
command, tell it to create and object, set all its parameters, etc, and 
the return from the function would be another array with the responses 
from each (as in error messages, or generally returns from each executed 
statement). You could also using the same above method, set it up so 
when someone creates and object, and changes some parameters within the 
same batch function,  give the object its id in the usual way on the 
server, execute all the params etc, with the same object # again on the 
server side, and then in the end, in addition to the returned 
errors,etc, include the object number for future reference.

Dunno, just an idea (btw, sorry bout the length, i suck at keeping 
things short and simple)

--Pete


Micah Dowty wrote:

>Hi,
>
>Another consideration for the new object model, is in optimizing the wire
>protocol. Currently PicoGUI always requires a response for every request,
>and in order to create an object then set properties you have to wait for the
>object ID to be returned, then use that ID to set properties.
>
>The solution I was planning on using to solve this was having the client
>generate IDs rather than the server. In the old handle system, this would
>involve two handle spaces- a per-client space and a global space, with
>the server owning a mapping between the two. In the new capability system,
>it since the IDs are allocated randomly anyway it would just involve a
>cryptographically secure random number generator in the client.
>
>But, I don't like the idea of forcing the client library to know how to
>create new object IDs- if a better random number algorithm is invented, or the
>scheme changes entirely, clients shouldn't have to know.
>
>My latest wacky idea fo circumventing this is to make the network-transparent
>version of the RPC layer actually a very simple virtual machine. For example:
> - client creates an object, the ID is pushed onto a stack
> - client uses that ID to set some object properties
> - client asks for the ID to be sent back to it
>
>Or even more complex but still useful uses:
> - client retrieves the ID of a global object, for example a read-only
>   list of server properties
> - client retrieves the ID of the "Operating System" key from that list
> - client asserts that the type of that object is a string
> - client asks that the object's contents be sent back to it
>
>In the object kernel, such a virtual machine for making queries would be very
>simple to implement. Creating a simple way of forming the queries would be
>harder. One method would be for every request the client makes that executes
>remotely, an identifier for that request is returned rather than a real answer.
>(a little like "promises" in E) That identifier can be used in making further
>requests, and it's automatically translated to instructions referencing the
>earlier request. If the identifier is used in an object local to the client,
>it is requested to be sent. This could be done explicitly in C, or via operator
>overloading in languages that support it. Perhaps it could even use an
>asynchronous mechanism like promises in E.
>
>  
>




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com