[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