[Lazarus] GUI development for web UI

[Marcos Douglas]

2010/12/2 Michael Van Canneyt <michael at freepascal.org>:
>
>
> On Thu, 2 Dec 2010, Marcos Douglas wrote:
>
>> 2010/12/2 Michael Van Canneyt <michael at freepascal.org>:
>>>
>>>
>>> On Thu, 2 Dec 2010, Marcos Douglas wrote:
>>>
>>>> On Thu, Dec 2, 2010 at 1:12 PM, <michael.vancanneyt at wisa.be> wrote:
>>>>>
>>>>>
>>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>>
>>>>>> W dniu 2010-12-02 11:38, michael.vancanneyt at wisa.be pisze:
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>>>>
>>>>>>>> W dniu 2010-12-02 09:25, michael.vancanneyt at wisa.be pisze:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> ExtPascal uses threads to handle multiple connections. I
>>>>>>>>>>>> remember
>>>>>>>>>>>> you
>>>>>>>>>>>> don't accept this way, right? BTW, what is there wrong if
>>>>>>>>>>>> ExtPascal
>>>>>>>>>>>> uses threads?
>>>>>>>>>>>
>>>>>>>>>>> I accept using threads, but not the way ExtPascal does it.
>>>>>>>>>>> Threads
>>>>>>>>>>> should be
>>>>>>>>>>> optional. In extpascal, the thread is equal to the session: if
>>>>>>>>>>> you
>>>>>>>>>>> have many
>>>>>>>>>>> sessions, the application will create as many threads as there
>>>>>>>>>>> are
>>>>>>>>>>> sessions.
>>>>>>>>>>
>>>>>>>>>> I use different architecture: each session has own thread and each
>>>>>>>>>> connection has own thread. Sessions are separated from connections
>>>>>>>>>> and
>>>>>>>>>> communicate via FIFO queue.
>>>>>>>>>> Session runs whole life time in the same thread. With this i can
>>>>>>>>>> use
>>>>>>>>>> modal form and thread var in the same manner, as normal (desktop)
>>>>>>>>>> application.
>>>>>>>>>
>>>>>>>>> I understand this is the easy way.
>>>>>>>>>
>>>>>>>>> But you don't need this architecture to do that. As long as a
>>>>>>>>> single
>>>>>>>>> request
>>>>>>>>> runs in a single thread, there is no problem with decoupling
>>>>>>>>> sessions
>>>>>>>>> and
>>>>>>>>> threads, and still be able to keep everything in memory.
>>>>>>>>
>>>>>>>> I dont understand.
>>>>>>>> I parse single request in single thread (for each request new
>>>>>>>> thread)
>>>>>>>> and what can I do (other) with sessions?
>>>>>>>
>>>>>>> One scenario looks like this:
>>>>>>> - Request comes in (on whatever thread).
>>>>>>> - Determine session data (your form) for the request.
>>>>>>>  Session data is in a global list.
>>>>>>> - Find a thread to handle the request.
>>>>>>> - Pass session data to thread and let it handle request.
>>>>>>>
>>>>>>> Another way is
>>>>>>> - Connection is accepted.
>>>>>>> - An idle thread to handle request is found.
>>>>>>> - Thread looks up session data from data in request.
>>>>>>> - Thread handles request using found session data.
>>>>>>>
>>>>>>
>>>>>> At the beginning I use second attempt, after that first. But both have
>>>>>> limitation, because not follow (not act as desktop OS) desktop
>>>>>> architecture.
>>>>>> There are  not pass to more complicated application (when it is
>>>>>> porting
>>>>>> from Delphi).
>>>>>>
>>>>>
>>>>> This is correct, but I assume that when starting a web application, you
>>>>> will start with a fresh design.
>>>>>
>>>>>> 1. All task of application should be prepare as response for request,
>>>>>> there is problem with modal forms, which stop and wait to user action,
>>>>>> and
>>>>>> after response go on (next statement in current procedure, not other
>>>>>> ).
>>>>>> 2.  When application is busy for long time with preparing response,
>>>>>> its
>>>>>> no chance to make simple response with message of waiting (or progress
>>>>>> bar)
>>>>>
>>>>> I don't see the connection of these problems with how threads are used.
>>>>> A simple WaitForEvent()/SetEvent() should do this.
>>>>>
>>>>>> 3. With second attempt session data is computing with different
>>>>>> threads,
>>>>>> thus thread vars can't be used
>>>>>
>>>>> They are only a problem if you use global variables. You should never
>>>>> use
>>>>> global variables, unless maybe the database connection and global
>>>>> application configuration.
>>>>>
>>>>> None of my 4 web applications uses global variables (except said
>>>>> database
>>>>> connection and global configuration object). The other programmers have
>>>>> not yet complained. They know global variables
>>>>> are evil from their work on our regular desktop program :-)
>>>>
>>>> How do you work to manipulate sessions?
>>>
>>> There is a global sessionlist (simple hashlist: string is session GUID,
>>> object is session module).
>>> based on the session cookie, I get the session. All other things are
>>> stored
>>> in a descendent of the session module.
>>
>> There is just a global sessionlist accessed for many threads, at the same
>> time?
>> The fpWeb framework manages thread conflicts?
>
> No, it does not. The sessionlist is not in fpWeb (although I have planned
> that), only in some private code (the list is obviously protected with a
> critical section).
> What conflicts do you expect ?

Conflicts type of Read/Write where 2 threads uses the same session, at
the same time.
But you said the list is protected with a critical section, so... that's ok.

Now... why isn't in the fpWeb?  :)


Marcos Douglas