Hi Mindaugas,
during process_event_loop() events are processed inside items_edit_handler() function, and this event handler can access workareas opened in a parent dialog (item dialog), private variables of item_hadler(), etc.
I didn't inspect the code yet, but it would be nice to be able to pass LOCAL vars (f.e. array/hash container of values) down the path. To make it possible to avoid memvars.
Other major changes ===================
[...]
- socket.c is more multithread GC friendly (using hb_vm[Un]Lock());
This answers one of my questions. Next question: Why don't we apply these to our core? It's a waste of resources to have two socket APIs.
- error handling. Runtime errors in "user" code does not cause server crash;
This also answers one of my questions. Thank you.
One thread per session ---------------------- Pro: * OK, if there is a limited number of clients actively using web application Cons: * not scalable solution for sites with thousands low activity users (will keep a large number of inactive threads)
Yes, but if we keep in mind business applications, they aren't typically used by several thousand users. In case of that many users it's also possible to use extra instances of uttpd executable on alternate IP/machine/port. To get around the different IP/port issue an uhttpd gateway can be implemented to distribute the load between uhttpd server instances running on multiple servers. Anyhow this plays well with the direction CPUs/servers are taking these days, more and more cores and parallel processing.
Roadmap ======= I'm not sure if I will not delete the whole sessioned threads, modal page handlers, and widgets in next version of uhttpd. But there are
IMO they shouldn't be deleted.
a few things I know I will implement: * Templates Perhaps this can change widgets a lot. Only complicated widgets will remain. Simple widgets and layouts will move to templates.
Sounds good. Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
