[Lazarus] Lazarus make me create better apps

[Michael Schnell]

On 05/05/2010 06:29 PM, Razvan Adrian Bogdan wrote:
> The mobile world is now a perfect place for Lazarus to "sink it's
> teeths into" if it knows how to occupy this space where there is
> little competition on the RAD side of things. On the web part after
> many years of Java slows apps, PHP code that let's you hit you fingers
> with a big hammer and ASP.NET <http://ASP.NET> technology that seems
> to be so hard to learn, Lazarus has a big change to make something
> that integrates easily on the Server and the Client side, maybe using
> NaCL on the client to build safe apps or simply "compile" to JS, Flash
> and Silverlight.
I recently invested some time to investigate server-site programming
with Lazarus.

There are several issues:

1) new __functional__ GUI-less Widget Type

A decent CGI-type of program should not have any linking to a GUI system
(such as the Windows Graphical APIs or GTK).  To do decent
"Delphi-Language" programming, event driven programming and threading is
essential. Currently, in the LCL the event queue, necessary for event
driven programming, e.g. using TTimer or thread communication is not
available unless you activate a GUI. (Currently only having worker
threads notify the main thread via an event queue is used in any Lazarus
or Delphi-Type programs is common, event queues for worker threads would
be nice to have but seemingly never requested by anybody but me - even
though MADSHI seems to provide this for Delphi.)

For decent GUI-less applications, a new "Widget Type" would be necessary
(at least for Linux projects) that avoids GTK /  QT binding but provides
an event queue. I started to do this (see some other "CGI"  or "noGUI"
threads here), but I'm busy with other stuff right now. (I do know that
this is possible: MSEIDE does provide this, but for Lazarus as much LCL
code as possible should be reused for this issue.)

A prerequisite necessary to be done to the common (shared by several
Widget-Types) LCL code would be moving the code necessary for doing the
event queue for the main thread out of the "Forms*" files, that provide 
the basics of the GUI interface. that should be a quite doable task.


2) Silverlight / Moonlight

I feel that Silverlight / Moonlight is a great way to create multi-tier
applications (working around the abysmal HTTP interface between the
sites that is necessary to use due to the worldwide lack of competence
in the IT departments, preventing decent bidirectional TCP/IP
communication.)

Technically, on the server site, Silverlight / Moonlight is just (fast)
CGI with some nice files on the server providing HTML pages, the CIL
(".Net code") program to run on the Client, and some Java script and
Java byte code for the Client to start the CIL program and have it
communicate with the server.

To do this, it is __not__ necessary that the server part and the Client
part are done in the same programming language. Moreover it is __not__
necessary that the server part is done in CIL (.NET/Mono) code. Moreover
I think ASP.NET (as Microsoft defines it) is not necessary either.

Of course for Lazarus fans, it would be really nice to do the client
part in an Object Pascal language, too. Currently there only is Delphi
Prism that can do this. AFAIK, the compiler - other than the IDE - even
is fee (as beer). Doing a CIL compiler for Lazarus seems to be far off
right now.

For the server site, on top of the "functional" GUI-less Widget Type,
Lazarus would need to provide an application or Widget Type that manages
the communication with the Web server. I suppose, in Linux (Apache),
this would be fast CGI, in Windows (when using IIS), this would be ISAPI
(maybe using a "gateway" ISAPI dll converting the ISAPI traffic into
fast-CGI, as debugging a dll could be very difficult to do).

Moreover the "comet" technology needs to be supported to allow for the
server application to notify the client asynchronously.

Of course a method to do an event-programming enabled fast CGI
application framework (that allows for more standard events (TTimer,
thread communication, etc.) and not _just_ the events triggered by the
client, and that also supports "Comet" out of the box would be desirable
for "normal" CGI projects, even before the stuff necessary to do
Silverlight / Moonlight would be very desirable


3) Flash

A colleague of mine indeed did this (using Delphi, IIS, ISAPI, and
RemObjects SDK on the server site and Flash Action Script on the client
site, defining a communication based on SOAP). So this in fact is
possible (RemObj SDK is commercially available in source code and
certified for FPC, but you of course can do RemObjects work-alike stuff
on your own).

He did this two years ago, as a (maybe) usable Silverlight SDK was only
available as Alpha state. I suppose nowadays he would do the project
using Silverlight and Delphi Prism.

4) IDE
To do sensible debugging for GUI-less programs support for decent
viewing of the "Writeln" output while debugging.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20100506/baef4981/attachment-0004.html>