[Lazarus] GUI development for web UI

[Dariusz Mazur]

  W dniu 2010-11-24 19:06, Michael Van Canneyt pisze:
>
>
> On Wed, 24 Nov 2010, Dariusz Mazur wrote:
>
>>>> That's not true. Transfer every action to server is very simple 
>>>> task, and computing results also. Thus (on my web app) it took less 
>>>> than 10ms and every user very rare generate more actions than 1 per 
>>>> second.  Computing and sending pdf reports took much more (more 
>>>> than 90% of working time). As I observe two on core machine can 
>>>> work 100 users concurent without problem. With more can be problem, 
>>>> but  with memory.
>>>
>>> Yes, I remember my discussion with you. I also remember that the 
>>> round trip time I observed is over 100 ms, which is noticeable. 
>>> (maybe not on intranet, but definitely on internet)
>>
>> You told about scalability.
>> 10ms is on server, on user side You should add transfer as ping (but 
>> this not load server)
>
> Let me put it differently. In the interface I was talking about, I 
> need exactly 3 HTTP requests, no matter how much the user clicks/hits 
> keyboard to set checks:
> 1. Fetch form 2. Fetch data.
> [grid is built on client using fetched data]
> 3. Save Data (user presses save buton)
>
> Your implementation needs 3 (maybe 2) requests to fetch form and data 
> and process save, plus additionally a request for each user 
> click/keyboard hit to set a check.
1.Fetch form with data
  after user action: request what should change: server test its 
validity, and generate new value for changed widgets
on most cases it took only one frame
2.Save button send nothing but number of button


>
> If that is correct, I don't even need to build these 2 systems to know 
> that my system will scale better.

>
> And - unless I understand your code wrong - you keep the complete form 
> state on the server ? (I.e. keep a pascal instance of all visible
> TForms and controls in memory).
yes, then same as in desktop,
but also compute of data,  size of "visible" control doesn't matter with it
>
> I don't need that at all. The amount of data I need on the server per 
> user session is roughly 200 bytes, and it doesn't much change during 
> the session.

In module computing as OLAP I need 10..100MB during session

>
> Again, if my assumption is correct, my system again scales better, 
> because it does not need nearly the memory your system uses.

Of course. I didn;t say not. But many Delphi todays application need 
involve strong interaction between database and user front end. Very 
often, after user actions, rather complicated computation on huge amount 
of data is done, and its transfer to forms.
My approach has better scalability from programmer side: I don;t need 
thing about browser, what should compute server and what not. Browser 
paint beautiful widgets (with CSS3,HTML5) similar as OS Windows or GTK, 
QT. All rest i've done without care which widgets set will be used.  
That is enough fast to service 100 concurrent user , with higher demand 
I can  use cluster.


>
> Looking at recent trends (Ajax, rich client interface toolkits) people 
> agree more with me than with you. But I may definitely be wrong; 
> everybody sees the world through his own spectacles...
Most of webapp are rather simple (counting forms and controls) compare 
to desktop app. For example even advanced internet shop has ten times 
less function than average store or POS application.
We talk about choose between fat and thin client. Both have good and bad 
use case.

>
>>> Secondly, you have not very demanding users and/or GUI, it seems :-)
>> Of course this is not game application, but on every ERP application 
>> (like my)  are places with rather sophisticated GUI.
>>
>>> I'll describe an interface which I currently have: A grid with about 
>>> 600 checkboxes (don't ask why, they want it so).  Users click the 
>>> checkboxes in rapid succession, thus generating much more than 1 
>>> event per second.
>>
>> I have forms with similar widgets too. Second: faster than clicks is 
>> keyboard.
>
> Well, most likely not if you must check which key was pressed, discard 
> bad keypresses etc, on the server.

On ordinary input not, but I use this on dictionary searching thought 
grid. I simply observe what users do in real.


>
> I also proposed keyboard but they require the mouse :(

This is user choose, not us. Both should work good. Today i thinking 
about fingers (on iPhone, Android)

>
>> But even that: its no problem when response arrive after next click. 
>> If response is under 300ms users thinks : "that is at now"
>
> On average the user sets 50 checkboxes before he presses save.
> 50x300ms = 15.000 Ms = 4 minutes just to process the checks ?
> I don't think so :-)

You don understand. This is not sequential but pipelining. Man need 
50*100ms (I dont think its so fast) Server need 50*10ms. Browser (and 
user) don't need wait to response


But different behavior of user: after 10 min and clicking 50  user press 
RELOAD on browser: whats happens?




>
>>> But if you believe in it: why not cooperate with the Lazarus team and
>>> create a web widget set ? All options must be explored, you 
>>> obviously have a good basis for it, so why not share it 
>>
>> I try to share my work  (without this hope I simply not write this 
>> post) but nobody is interesting.
>> link: http://www.emadar.com/fpc/xwebdemo.zip
>
> I think most people on the Lazarus list simply didn't know about it.

>
> But I hope for you that this will change now, and that people look at 
> it and prove me wrong. And in doing so, hopefully they
> create a good Lazarus widget set.

I hope so.
>
> That is finally what it is about for me: advancing FPC/Lazarus.
> I have my idea about how to do this, but if other ideas exist: the 
> more, the better.
>

-- 
   Darek