[Lazarus] HTTP client/server components committed.

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Tue May 17 10:34:58 CEST 2011



On Tue, 17 May 2011, Michael Schnell wrote:

> On 05/16/2011 05:27 PM, michael.vancanneyt at wisa.be wrote:
>> 
>>> Will this allow  to create a project with a browser based remote GUI ?
>> Yes.
> Great. looking forward to test it.
>>> Will this help to create a Lazarus Application running as a Daemon on an 
>>> Android device and have the user access it via the standard Android 
>>> browser ?
>> Yes.
> Great. My son does have an Android device, and he also did succeed in setting 
> up Android/386 in a virtual machine on his PC. So we might be able to test 
> this, too.
>>> Will this (on Linux) allow for TTimer, TApplication.QueueAsyncCall, and 
>>> TThread.Synchronize without a binding to an external Widget Set (or 
>>> X-Server) ?
>> Well, TThread.Synchronize works already as-is without widget-set, provided 
>> you call CheckSynchronize in the main thread on a regular basis.
> Polling of course is not a decent way to handle inter-Thread-communication, 
> especially as "on a regular basis" (e.g. each 200 msecs, while the main 
> Thread continues to be responsive) is not possible without a TTimer.

Any implementation will always use polling. You may hide it under some kind
of abstraction, but it's always polling. On unix with select() or epoll(), 
on Windows with PeekMessage/GetMessage and friends. Your Delphi windows timer 
uses PeekMessage/GetMessage by the message pump as well.

>> And for the other features: no, this will not allow for it, but also will
>> not interfere with it. They are just components that implement the HTTP
>> protocol: sending and receiving text messages. No more, no less.
> Anyway, this seems to be a good starting point for a full featured "Widget 
> Type". I'm sure that its possible to add an Event Queue re-using and 
> improving the code provided in the FPGui Windget Type, which already (maybe 
> partly) implements the Event Queue for TTimer, TApplication.QueueAsyncCall, 
> and TThread.Synchronize based on the native Linux (no-GUI) API.

I think you're mistaken there. Till a couple of months ago, fpGUI's TTimer was 
buggy, it didn't react unless you moved the mouse in the app, both in
Windows and Linux if I recall corretly.

While TTimer has been fixed almost immediatly by Graeme after I reported it, 
the above shows that it is tightly intertwined with the GUI.

Michael.




More information about the Lazarus mailing list