[fpc-devel] Android native application with local webserver

[Michael Schnell]

On 04/14/2011 05:12 PM, Dariusz Mazur wrote:
>  I've implement message queue (like in Windows), also VCL/LCL  style 
> communication with widgets. TThread.synchronize was reimplement, 
> because there is many "Main thread" - per each session. All enough to 
> use the same source do build desktop and web application.
GREAT !!
Would it not make sense to make this a new LCL "Widget Set" ?

>>> server work in own thread, each request in own, each session (whole 
>>> application for one user) in own
>>> communication between request thread and session threads are done 
>>> via FIFO queue
>> So the "Server" is the "Main Thread", 
> No , I mean this is main thread of listen socket
Sorry I can't follow you here :-( .

>> which is supposed to do most of the "Office Logic" work, 
> "office logic" and changes in used widgets (controls)  is done in 
> session thread, and when computing if finished,  request thread 
> prepare response, based on new state of "visible" widgets, there are 
> mutexes, to coordinate flow between this two threads.
Is this invisible to the application programmer, so that (s)he sees just 
one thread with no need to synchronization ?

>> including handling the TTimer events. IMHO, it's not a good idea top 
>> do the Office Logic stuff directly in the threads that are fired by 
>> the single requests, as this will ask for huge problems with mutual 
>> access of commonly used data, which the user does not really want to 
>> handle with a great count of CriticalSections or similar 
>> synchronization stuff. I feel that it would be good to have the 
>> "requests" transformed to "main Thread Events", so that a "normal" (= 
>> not  thread aware) user is able to do the programming seeing only a 
>> single thread.
> In my attempt single session (like desktop application) work in own 
> thread. In session can be use inner threads, events, modal windows 
> etc. similar like in desktop.
Sorry I can't follow you here :-( .

>>> I don't think so
>>> But when browser send request, server don't response at now, only 
>>> wait 30s and then (if its nothing to respond) send message to 
>>> browser with order to repeat request.
>> OK. If the program works only on request and the java code does a 
>> long sleep, the CPU use will be decently low. But of course this will 
>> not provide a very agile experience to the user.
> Why. When server want to push to browser response earlier (response 
> took less than 200ms including ping), when browser (user) want  ask, 
> then send new request, no one wait
Sorry I can't follow you here :-( .  (Julian, can you help ?)

-Michael