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://www.vasoftware.com > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! ------------------------------------------------------- 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
