[Lazarus] HTTP client/server components committed.

[Michael Schnell]

On 05/17/2011 10:42 AM, Graeme Geldenhuys wrote:
> Correct. While that design may not be ideal (please mention new designs
> if they exist), it is perfectly acceptable in fpGUI because after all,
> fpGUI is a 'gui toolkit' for 'gui applications'. ;-)
I really would like to test the newest version :-) .

How is TTimer implemented ? Does it really have a binding to the 
underlying X ?

When I once was able to test it, I did see the problem that events 
scheduled by threads only were acknowledged by the main thread when a 
GUI event had been fired, too. So there was a binding to X. I have no 
idea how X events are received by the main thread, so I can't see what 
might be happening here.

OTOH, a GUI-free Linux Widget set could be done by using nothing but a 
single epoll() to wait for all events (e.g. Timers and Threads). I 
suppose your expertize on the implementation of the event queue itself 
should allow for removing the GUI binding and do an implementation that 
get's the main thread notifications from epoll(). Making the message 
queue itself a dedicated object in a dedicated unit outside of the 
Widget Type code would allow for a single implementation used as well by 
fpGUI as by GUI free Widget Types.

-Michael