Sebastian Günther wrote:
The application of course gets compiled as usual and runs on the server.
Maybe it gets compiled to javascript and the javascript runs on the
client. Talking to some custom-server(-script?) running on the server.
JavaScript will only be used for drawing and content creation, and for
event propagation of course. Communication using AJAX or JSON, but
using the synchronous version of HTTPRequest (remember that most
desktop widget toolkits are working synchronous as well, for good
reason). For example, the canvas: Drawing commands will be buffered,
and as soon as execution returned to the main loop, this command
buffer will be send to the JavaScript client. (Of course there might
be special cases like painting in a canvas and immediately reading
data back from the framebuffer. In this case it might be necesseray to
emulate the whole painting on the server using a memory image.)
Really all kinds of widgets can be emulated using JavaScript and DHTML.
That is my estimation as well.
This approach surely would work quite well -- but it would be quite
slow, dependent on the exact application.
Any comments? :-)
Could we have a demo app of this working so we can demo it at Systems-2007 ?
(even just a 20 line, 4 control form would be enough)
to see what people say....
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
