On Tue, 21 Aug 2007, Sebastian Günther wrote:
> Hi Michael, > > > Michael Van Canneyt schrieb: > > > > This is always so in Client/Server. Global variables are a big no-no. > > Of course. I just tried to identify potential problems when converting a > desktop application to a web application. > > > > The widgets itself are not the problem; They are the easiest. > > Ok it's still work to implement them, but it's possible at least. > > > > The problem is the user code. > > Only performance-wise I think. Yes, but performance is everything. Your app may look as a desktop app, but if the responsiveness is zero, no-one will use it. > For example: Emulating something OnDrawCell. This _cannot_ be done on the > server. Technically yes, but the performance... Many other events as well :/ > > > This approach surely would work quite well -- but it would be quite slow, > > > dependent on the exact application. > > > > Like Intraweb. > > ...and several other web toolkits as well... > > > > > 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. > > Btw, the Mono project is implementing Silverlight on Linux (called Moonlight). Maybe, but I'll be damned before I install mono. I'll never forgive Novell for switching basic system management tools to mono in SuSE. Bulky and dog-slow. > But this would be just an option, of course. It won't replace the JavaScript > stuff (at SL uses JS as well), but could make widgets more responsive. This is > really just an option for the future. Perhaps as a Flash based solution would > be; but I don't know Flash good enough to tell if this would be a viable > solution. I would not do this. Maybe later as an add-on option. I simply HATE it when some website requires plug-ins. I do most browsing simply in Konqueror, and most plugins do not work there. The web is standardized for a reason, after all. Therefore any web solution should stick to standards - at least the basic version. You can later add 'plugins' or whatever. > > You might just as well code in flash or Java. > > Hm. Java SWT as frontend? ;) > > > > > 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. > > I don't think so. But it depends what you want. Simple: Uncompromised speed of development and minimal traffic between client and server. > My approach would ensure that > existing projects can switch to web techniques with a minimum amount of > changes necessary. (Of course, some serious issues remain, such as printing. > But to be honest, in most cases this are the usual areas where it gets > difficult to switch a Delphi app to Lazarus, or multi-platform issues > anyway... and, btw, where Delphi often breaks downwards compatiblity. I'm > talking about this 'nice' libraries such as QuickReport.) That is why I think such an approach is not doable. I do not have a single application that can be switched to web. Not one. Any application you want to switch to web will need to be reworked work anyway, except some vanilla apps. Since no-one makes vanilla-apps, it's futile to even try IMHO. That being the case, my favourite runner-up solution is a set of widgets that is designed for the web. > > But since we are nowhere near that, we'll have to do as you suggest. > > okay... > > > > 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. > > > I'm not sure. As I can see WebRAD is an extension to Delphi which introduces > special components for web development. This has nothing to do with our goal > of a 'LCL web target'. It seems we've been talking cross-targets :-) I had exactly such components in mind. The standard components are not workable IMHO, since many of the events are simply not available in the browser, and therefore would have to be recoded anyway. (the keyboard events, to name some) Also, custom drawing all possible widgets might prove rather slow :/ But we'll see. The starting points of any solution is the same: - the rendering engine, - communication engine, - session management, - caching These must be designed first. > So, what to do? My suggestion is to start with a framework for dynamic web > content creation, somewhat similar to that what VCL for PHP is doing. Putting > the LCL implementation on top of such a library would enable us to write > specialized components easily, before the quite hard to do optimizations work > (there are not only existing projects, but also new ones, which could use > special (faster) widgets.) This we will need anyhow, whatever the end target is. That's the basis. See the 4 points above. > And, btw, as a long-term goal I see this as a starting point for a real good > content-management-system-style software. Real high-level components. But for > this we need frame support in Lazarus first (with having HTML IFrames as a > quite good equivalent :) ), which hopefully will be finished in the not so far > future. > > Other loose ideas and topics: > - What about some investigation in plugin systems. > - Writing XML and CSS directly, or using the DOM units? DOM is good when you > cannot create XML in a linear fashion (as it is the case in fpDoc, for > example), but of course it needs much more memory and is slower that a linear > writer. I would opt for DOM as it gives more options now and in the future. Using direct XML writing is faster but harder to modify or hook into. The current web writer uses DOM. Since we'll make a native server, it'll be a lot faster than PHP or any other scripting language anyway. > - We need a good caching system. Especially if we decide to use DOM, which > _might_ be better for plugin systems. Each component must know in a way if its > XHTML or CSS content changed since the last cache generation. Additional it > would be good to know which parts of the output can be cached at all, and > which ones don't. Maybe this can only be done in a good way using the code > analyzer used for JS translation (later). This is not an easy issue, and I must confess that I have no idea about how to go about this. Michael.
