[Lazarus] New application type: HTTP standalone server

[Michael Schnell]

On 06/07/2011 02:41 PM, Michael Van Canneyt wrote:
> I want to see if we can integrate it in a TCustomApplication
> descendent (TEventApplication), of which the LCL TApplication can be
> made a descendent. If so, then the NOGUI widget type will
> automatically have an event loop and timer.
Sounds nice !

I vote for a kind of "general" implementation:

An TEventQueue class defined in a central location so that it can be 
used by any Widget Type (AKA "interface" implementation, AKA 
TApplication class derived from TCustomApplication, I don't know how 
this is related to the "Application Type" that is selectable when 
creating a "New" project.)

The TEventQueue class should provide the necessary hooks that 
theoretically would allow all (non-Windows) Widget Type implementation 
to be re-implemented using them. Maybe a partly virtual 
TCustomEventQueue class might be sensible to define the hooks and the 
basic functionality, so that the final TEventQueue derived from same 
again is implemented in the Widget Type code. With this I suppose that 
any (future) Widget Type implementation would be able to reuse the 
active code. With that maintenance would be perfect and optimizing the 
central active EventQueue code would make much sense. (AFAIK there are 
several more or less optimized implementations of self-sizing FiFOs 
around that could be considered to be tested against any initial 
implementation.)

Maybe in fact a future TApplication could be based on the 
TEventApplication you are planning (instead of directly on 
TCustomApplication as it seems to be done right now). If this is the 
plan, again I suggest that TEventApplication is done in a way that 
theoretically all (non-Windows) Widget Type implementation could be 
re-implemented as a sibling of same, dumping the active event-queue code 
done in the individual Widget Type implementation.

> Well, based on your various descriptions and questions, I think it can
> be used to create this widget type.
Sounds good :).

> ... This is exactly what I want to establish.
Please let me know if I can be helpful in any way.

For testing I already have a quite generally usable testing project.


Suggestions:

I think, it would be good enough to implement 
TEventApplication.QueueAsnycCall() as a central entry to the queue. 
Other mechanisms (such as TThread.Synchronize(), PostMessage(), and 
PostThreadMessage() ) can just use it. This would facilitate the code 
maintenance.

As you are a very active core member of the community, maybe you can 
improve the FPC RTL, too. Here, TThread should be enhanced by the 
TThread.Queue() procedure. Same is implemented in Delphi since years 
(but not decently documented in the Delphi help of all versions). 
TThread.Queue() would be nothing but a call to QueueAsnycCall with one 
argument.

Thanks again,
-Michael