This is one way the current protocol could be improved- it could even
be done without breaking compatibility, by adding a "batch2" request
or something. However, it would be tricky to make this functionality
accessable easily from the client. You can already do something almost
as good using widget templates- widget templates are constructed entirely
server-side, but you need a round trip to retrieve a handle to a widget
created with WTs.
The new protocol will probably internally use a simple VM language.
>From the users' perspective, it will very likely use a "promise"
mechanism like what E uses- whenever you make a request to the server,
(any object, really) it never blocks. Instead of returning an actual
value, it then returns a 'promise' for a value. Further operations
can be performed on this promise, and they will be queued for execution
later and also return promises. When you need a local value, you can
schedule functions to be executed whenever a promise is fulfilled,
and a broken promise can throw an exception.
On Thu, Jan 30, 2003 at 10:41:16PM -0500, pete rippe wrote:
> 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
