Hi all,

There is a new version of the Webdesign package available for download.

You can find the package here:
http://services.cnoc.nl/lazarus/index/fclweb

This package can be used to develop webpages for FCL-Web using a Lazarus-designer.

Changes are mostly bug-fixes, and there is a new focum-example.

Regards,

Joost van der Sluis

Joost van der Sluis wrote

This package can be used to develop webpages for FCL-Web using a Lazarus-designer.

Can you elaborate what the package does and or provide a link to a documentation ?

it seems to be something similar to ExtP (which is a Lazarus package to help using ExtPascal, which helps Pascal programmers with using EXTJS <by Google> )

-Thanks

See my mail from jan 24th.

it seems to be something similar to ExtP (which is a Lazarus package to help using ExtPascal, which helps Pascal programmers with using EXTJS <by Google> )

I've used some ideas from ExtPas, yes.

This is more general, though. You can use it with jQuery (which is provided) but also with ExtPas (or Qooxdoo if you want). Although there's no code for those yet.

Joost.

Joost van der Sluis wrote

See my mail from jan 24th.

Thanks. Found it in the Backlog. (I (was not subscribed to this mailing list at this date)

Do these web-applications support persistent CGI programs using AJAX / Comet ?

If yes, how is this done ?

If no, do you want to cooperate with me on this (see my message 02/11 12:28 (creating a Lazarus package "NoGUIApplication")

-Michael

In your mail from jan 24 I found:

"adds some functionality for server based and client site event handling"

This sounds as if persistent CGI would be supported.

Would it be possible to create a CGI that allows for this:

- The Browser surfs to the CGI location
- some Web page is shown containing some kind of Memo-Box
- the user does nothing at all
- whenever a character is received at the server's TTYS0 port, it is shown in the MEMO

- no project specific Java script programming is done (just using the AJAX / Comet stuff)
- no fast polling is done by the Java script code, Only avoiding TCP/IP timeout requites some activity now and then.

Another example (avoiding any hardware binding) would be a simple http chat cgi.

-Michael

Not without polling

Joost.

I'm not sure what you mean by "polling" here.

Of course a chat CGI (and the other examples I mentioned) do need polling for remote updates of the web page by Java script on the Browser site to avoid HTTP timeout. To avoid unnecessary communication, AJAX/Comet can be used to create "hanging" HTTP requests that only are answered by the CGI program when an update is available or before a timeout hits.

OTOH with the standard CGI paradigm, with each HTTP communication the CGI program starts and finishes. So the CGI program does not have any permanent "states". Thus a "chat" would need to store the text to be transferred in a file or a database, creating a huge overhead.

With the "persistent" CGI paradigm, the CGI program keeps living and can transfer the text it received from one user to the other just by managing the requests that come in from the web server as byte streams.

The NoGUIApplication package, I am planning, will allow for doing such persistent CGI applications. I feel that you could create a very viable enhancement for WebDesign, optionally enabling persistent CGI, using NoGUIApplication. So I'd be happy if you can test this, once I'm able to provide a working version.

-Michael

If I understand your explanation correct, all this already exists since quite some time in the fastcgi application type. See the custfcgi and fpfcgi unit.

Michael.

By polling I meant that you need it to see if there are any changes. Not only for the timeout. That's because you can not use a "hanging" http request.

This can be solved, though. (I don't even think it's much work, we only need an interface to read the output from the client after the initial request-headers are parsed. Now the rest of the input is simply ignored)

OTOH with the standard CGI paradigm, with each HTTP communication the CGI program starts and finishes. So the CGI program does not have any permanent "states". Thus a "chat" would need to store the text to be transferred in a file or a database, creating a huge overhead.

That's not true. What you could do is keep your program/module persistent in memory. In every cgi-call from the client you include a session-identifier. Then you can decide on the server side to which persistent module this call has to be referred to.

With the "persistent" CGI paradigm, the CGI program keeps living and can transfer the text it received from one user to the other just by managing the requests that come in from the web server as byte streams.

Yes, but not using a 'byte stream' but separate requests. (byte stream is offcource also possible, but see above)

The fcl-web examples that are online now, all uses rest-handling of data. If I have some more time i'll write an example to show the behaviour as described above.

Joost.

Michael Van Canneyt wrote

If I understand your explanation correct, all this already exists since quite some time in the fastcgi application type. See the custfcgi and fpfcgi unit.

Thanks for the pointer.
I'll take a look.
-Michael

AFAIK, the web server will not send anything to the browser unless it detects that the CGI program exits. So polling does not work, as the http client does not see any answers.

Yes, but not using a 'byte stream' but separate requests. (byte stream is offcource also possible, but see above)

According to my research this is not possible. But maybe I'm wrong.

The fcl-web examples that are online now, all uses rest-handling of data. If I have some more time i'll write an example to show the behaviour as described above.

Great !
Looking forward to this !

Thanks,
-Michael

Is there an example of a "fastcgi" project that uses a TTimer or something similar ?

Thanks,
-Michael

No, but a fastcgi application is an application as any other.

It cannot use a TTimer, since TTimer presupposes a GUI and an X server. It can use a TFPTimer, which does not suppose a GUI and X server.

Michael.

Michael Van Canneyt wrote

It cannot use a TTimer, since TTimer presupposes a GUI and an X server.

That is what I did expect.

It can use a TFPTimer, which does not suppose a GUI and X server.

Sounds good. So it might have an event queue.

I'll take a fastCGI Application in fact implements the NoGUIApplication that I need and I can use it, even if I will not do a CGI. Perhaps just the name is confusing...

My intention is to create a "toolbox" that allows to convert free running (embedded) "normal" applications to not needing the GTK binding (after having stripped them from the user interface). But they still do need things like Timers, TCP/IP communication, serial interfaces, threads (with "synchronize" and "postmessage" / "procedure...message")

I'll take a deep look at it :)

Thanks for your advice !
-Michael

In all cases I'm talking about fcgi, offcourse. Or you can make it an Apache module. Or, indeed Isapi. But the headers for this are still missing.

Note however that this is all really build for web-applications. If you want to make some embedded-remote-gui system. This all won't work and you have to build your own TApplication type, indeed.

Joost.

It doesn't need to. It has a web-server, which queues all requests, and sends them one-by-one to the fcgi application. (If you configure it right)

Maybe fastCGI Application in fact implements the NoGUIApplication that I need and I can use it, even if I will not do a CGI. Perhaps just the name is confusing...

No, it implements a fastCGI application. You can not use it for what you want. Otoh, what you want is not necessary to build a persistent web-application. That can be done much easier. (As is done in the fastCgi application)

Well, the fcl-web applications do not support timers, TCP/IP, serial interfases and postmessage functionality.

So you cannot use it for anything you want, would be my guess.

You can use the same mechanism as is used by the TWebApplication, though. Build your own TApplication descendent, which does all this. But I thought that was precisely what you are working on?

Joost.

Why not ?
My fcl-web application does a SOAP request to another server. What is this other than a TCP/IP request to another machine ?

Michael.

I see. What I intend to do can be extended be a persistent web-application, So there is an example of a persistent web-application that can't be done with fastCGI :).

OTOH, I feel that any persistent web-application can be done with a NoGUIApplication infrastructure, the advantage for those that _can_ be done as fastCGI applications is that with same, the normal "Delphi"-paradigm of event-driven main-thread programming can be used, making it a lot easier to use for experienced Delphi programmers without much CGI background.

That is what I supposed :( .

You can use the same mechanism as is used by the TWebApplication, though. Build your own TApplication descendent, which does all this. But I thought that was precisely what you are working on?

That is what I already have :).

But (see my earlier mails) I feel it would be more appropriate to do a new Widget Type than a new Application Type.

-Michael

There is no reason why fcl-web cannot be used for this; it is totally event driven. The only "event" currently defined is the request from the client.

This I really don't understand, and never have since you started the discussion.

There are no widgets in your application. It's a server application that sits in the background. So why create a new widget type ?

There is, if I understand you correct, an event loop.

All fine, but an event loop can be programmed in various ways, without the HUGE overhead of the LCL widgetset.

Michael.

Michael,

I've been using FreePascal and fpGUI on this 7" Linux touchscreen: http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390

I also need to run the same program (without the GUI) on similar Linux boards. What you are seeking is something I need as well. I hope we can keep in touch and get this accomplished.

Michael Van Canneyt wrote

There is no reason why fcl-web cannot be used for this; it is totally event driven. The only "event" currently defined is the request from the client.

I see. If nothing else is needed you are fine. :)
-Michael

I'm intending to do this as an open source project, hopefully as a Lazarus package to make it easy to use.

As I seem to be forced to copy a lot LCL code (i.e. the event queue implementation) from the "gtk" Widget Type folder into the folder I'll be using for the new Widget Type, I hope I can work with the Lazarus "powers" to move this code into a dedicated unit or include file to be used by both Widget Types.

I'll be happy if you could test the stuff once it's in a state you can take a look at. Please stay tuned; I'll post a message here once I have something I can show.

-Michael

Paul Breneman wrote

http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390

Nice !

The work I'm doing here is triggered by the need to use a very low power consuming processor PCB for this Delphi-program. This will be an ARM in the first intended implementation.

In fact the TX-TXP-7390 is an interesting hardware for some applications we intend. (There are some that do require a local GUI.)

-Michael

That still does not explain why you think it is necessary to create a new widget type instead of just implementing a more general event loop ?

Lazarus can be used perfectly for applications that do not have a widget set or do not use the LCL.

Michael.

I need to do a kind of tool box that allows my colleagues who do "embedded" Delphi programs, to create versions of same that - instead of a PC - run on a "headless" Linux enabled ARM-PCB (without any support for user interface). The necessary code changes should be as minimal as possible and the final source code needs to be compilable as well with Delphi - to create exactly the application that they already have - and with Lazarus - to create an application for the ARM PCB.

And these colleagues do use stuff like "TTimer", "procedure ... message", "postmessage", TThread.Synchronize, serial interfaces, TCP/IP, ...

The Lazarus team did a great work providing a decently Delphi-compatible LCL implementation to use Linux/GTK. And thus concentrating the solution for the additional differences (avoiding the GTK binding) in a new Widget Type seems the best way to go.

-Michael

Aha, now I get it.

So a typical case of "problem between chair and monitor"...

Well, I would re-educate my colleagues, nothing for it. Because before you know it, you'll find yourself re-creating the entire windows API, and where does that end... :/

Thanks for the explanation.

Michael.

I suppose a major part of the Lazarus users are Windows converts, so the Lazarus team is in the same boat :)

-Michael

It seems that you started on the ISAPI implementation. How is that going?

I meant that it is not implemented within the framework. It uses the webserver for all that.

Joost.