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
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel

Reply via email to