Re: 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-----