[Gambas-user] Future of webform component

[PICCORO McKAY Lenz]

I have had to substantially alter the project to make it work, I have many
doubts according to my poor understanding of the request vs. the response:

If all the data is transferred with pipelines, this implementation is not
scalable as such, I do not understand as for example, php that is
interpreted is so fast and popular instead of gambas, which is what makes
php faster, we know that php It does not run on threads.

It has been a good point of discussion, also keep in mind that in gambas
there is not a whole giant development team like in php or java, so let's
compare against php4 that it was still somewhat scalable, my point is that
other technologies work well so what is the fear that gambas are not like
java (as you said, a cgi only request per each client only) and his "tomcat
helper" (today more than one helper exists on the server side for java
deploiments)

As for the events, well in any web system the events actually occur in the
client, although we fool ourselves with things like ajax, although I cannot
give much opinion because I still do not handle the issue very well, but it
is also related to the I said earlier.

The idea has benef...

El lun., 30 de dic. de 2019 a la(s) 14:31, Benoît Minisini (g4mba5 at gmail.com)
escribió:

> Hi everyone,
>
> Here is a test project for you. It implements what I want to do for web
> development in Gambas.
>
> At the moment, the 'gb.web.form' component allows you to create web
> application with a GUI-like interface, but it has many problems:
>
> 1) It's a CGI script. So the entire GUI object tree must be rebuild at
> each request.
>
> 2) The only way to keep information between requests is the session,
> which is stored in an external sqlite database. You have to write custom
> code for handling that.
>
> 3) There is no event loop at the server level. I mean, when you open a
> modal message box, it's modal on the client side only. You have to rely
> on custom events to get the result on a modal message, and be careful
> with the implied code logic.
>
> The joined little project implements a CGI script that replaces each
> session by a process daemon.
>
> The process is created the first time a new session is created.
>
> All requests are sent to the session process through a pipe, and the
> response is get from another pipe.
>
> If nothing is received by the session process during 20 seconds, the
> process terminates automatically.
>
> The advantages of that method are:
>
> 1) The process is permanent. All information is kept between processes.
> No need to rebuild the GUI object tree, to reopen the database
> connections, and so on...
>
> 2) No need to store the session in a database or a file. The process
> memory *is* the session.
>
> 3) It will be possible to implement a true event loop in the session
> process. Modal dialogs will be modal on the server side too. Web GUI
> programming will really look like standard GUI programming.
>
> 4) Having an event loop, you will be able to watch file, open sockets,
> use timers... in the server process. For example, a WebTimer will run on
> the client side, but a normal Timer will run on the server.
>
> It's really like a telnet or a ssh connection between a terminal and a
> server.
>
> I see the following disadvantages:
>
> 1) If your application is big and if you have a lot of users, you will
> need memory and swap. But I don't think it's a big deal against the
> easyness you will get.
>
> 2) The data is copied between the CGI script and the session process. So
> it *may* make things a bit slower if you want to handle a big download
> or upload.
>
> 3) Beware that only the client can initiate a communication with the
> server. It will behave the same way as the current 'gb.web.form'.
>
> Tell me what you think about that.
>
> Regards,
>
> --
> Benoît Minisini
>
> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gambas-basic.org/pipermail/user/attachments/20200101/216a2cb5/attachment.html>