On Mon, 20 Aug 2007, Sebastian Günther wrote:
> Michael Van Canneyt schrieb: > > > > > Please explain why that isn't possible to do a conversion of such an app > > > using > > > Javascript ? > > > > Are you going to compile the pascal to javascript ? > > Hello *, > > as I already wrote Michael in private I'm thinking about developing a web > widgetset for LCL as well. > > My current considerations are these: > > The application of course gets compiled as usual and runs on the server. There > is only one major issue: A web application must be prepared for > multithreading, as there is one instance of the 'main form' per user access > (or session). But, if properly written (storing data in the main class, and > not using global variables), this is not a real problem. This is always so in Client/Server. Global variables are a big no-no. > 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. The widgets itself are not the problem; They are the easiest. The problem is the user code. > This approach surely would work quite well -- but it would be quite slow, > dependent on the exact application. Like Intraweb. > Btw, what we could do is to support Microsofts Silverlight; if this plugin is > installed, create all widgets using Silverlight, where you can use _all_ > widgets which .NET's Windows.Forms support. Nono, no dependency on Microsoft-Only technologies or plugins. That is definitely out. The browser, and only the browser: Standards based implementations only. I want the code to run on Linux as well and silverlight for instance does not. You might just as well code in flash or Java. > But back to JS/DHTML. To improve performance, I see only one way, the way that > Google's Web Toolkit is going: Analyze the source code and try to convert > single methods to JavaScript wherever possible, using some kind of JS version > of the FPC RTL. By time, this library would get bigger and bigger, improving > the performance step by step. But of course the source analyzer has to be > extremely careful about keeping the application state in sync between client > and server. That is exactly what Morfik does not need to do, because it converts ALL form logic to Javascript, and is hence much easier to code. It's the only correct way, IMHO, all the rest is patching-up. But since we are nowhere near that, we'll have to do as you suggest. Maybe webrad is a good candidate to start with as suggested elsewhere; It seems like it's been abandoned since 5 years, and maybe we could take it over. Michael
