RE: Re: about your concept

I probably didn't cover the scope of my idea far enough, so I apologize.  I
meant for all our "standard toolbox" widgets to have server-side painter
bytecode for rendering the widgets in all their states.  Then, when a client
comes along to connect, he informs the server of a few custom widgets he's
got, and upon initialization would send the painter bytecode for each
defined state of the widget to the server.  The server would then cache it
and recompile it into native code for later use.

Then there comes the problem of the server-client-server roundtrip you
stated.  That could be alleviated by defining custom widgets based on the
server-side widgets available, like you suggested.  Server-side widgets
would consist of simple things like scrollable lists, grid layouts,
textboxes, buttons, labels, scrollbars, tab controls, etc.  You could
compound all these together to define a custom widget.  Following that idea,
a nice way of uniformly defining custom widgets should be drawn up, for
example an XML-like structure (transmitted minimally over network).

And, as a fallback mechanism for custom widgets that can't be defined in
terms of the basic server-side widgets, the client could send the painter
bytecode on the fly for the current state of the widget that is completely
client-controlled.  Also, these bytecodes could also be cached and assigned
a server-generated unique identifier (sent to the client obviously, or have
client+server assume an incremental identifier).  Then the client would only
have to inform the server that "rendering bytecode ID# XXXX" should be used
now.

I'll think about this some more later.  Thanks for your input, Ulrik!

James Dunne
[email protected]

-----Original Message-----
From: Ulrik Mikaelsson
Sent: Thursday, July 22, 2004 10:55 AM
To: [email protected]
Subject: Re: [Y-devel] Re: about your concept

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thursday 22 July 2004 17.26 skrev Dunne, James(Summer Hire):
> As far as transferable widgets go, why bother using an existing
> general-purpose bytecode (e.g. ECMA MSIL) to render them?  That just
wastes
> resources JITting it and calling managed wrapper functions to the painter.
> Shouldn't we get right down to the root and develop some kind of minimal
> "painter" bytecode that is only capable of drawing?  That way, the server
> can recompile the bytecode into a trampoline function containing direct
> painter calls for speed and efficiency in rendering custom widgets.  Of
> course, for an initial implementation a pure interpreter would suffice.
Hmm, there's one little issue about attempting a simple "painter" bytecode. 
The widgets must not only render themselves, but they must probably also be 
capable of autonomous reaction to input events. For instance, when you click

a button, I don't think we want a server-client-server roundtrip to react
and 
render the pushdown-release animation, do we? Isn't the widgets supposed to 
be able to deal with something a bit more complex situations, like scrolling

a list autonomously without supportting client-side code and such?

Or is it possible to simply split the widgets into a bunch of common 
categories, and not specify alternate behavior from client-submitted code? 
Like, "This is a regular button, but I will simply provide my own 
drawing-routines, thank you very much" ?
I think that would be making it a little bit too simple, though. :-/

Regards
/ Ulrik

- -- 
Pardon this fortune.  Database under reconstruction.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/+NE069SELtZwIkRAjLPAJ9QrBWiVM49gG/OscQbDG7ZYLEtfQCfVcLS
kzxGMocOT/M6kLpO0fPOp68=
=G4iG
-----END PGP SIGNATURE-----