RE: another server I think my motivation for this is to separate the processes responding to live user load from the network.
If I understand correctly, the web2py instance and server is running as one process; the web2py applications are running as threads. So my first way of thinking is to start by putting non end-user realted stuff off on it's own process. The other piece is if offloaded tasks are big, they can exist elsewhere - for example (and I know hosting services will do this): webserver on one "box"; database server on another "box" - so this follows the pattern: If you need, you can separate these. as for daemons - what difference do you see between daemons and services? daemons are background processes, often spawned, children of what started them (init) - and in the web2py domain I don't see why the web2py instance can't check to see if there are services, and if so, spawn a child server which will initialize them..... but that's a lot of hypothetical detail..... my point is daemon, service; web- service, web2py-service.... lots of same patterns (in my mind) between all these, and that last one is what, it seems to me, we are trying to define.... so let's keep hammering at it! ;-) Regards, Yarko On Oct 9, 6:34 pm, achipa <[EMAIL PROTECTED]> wrote: > Massimo is right, what I'm aiming for is closer to daemons (it's just > that windows calls daemons services... damn terminology). I'd like to > underline is that this does not replace a system cron or other daemons > that do long running or very low level tasks with specific rights. If > you need to do something as root from cron, do it as root from cron. > On the other hand I really need the ability to be able to > asynchronously define and trigger small things which on the level of > the *applications*, not the system or the web server. One-click > application deployment through a web interface is not worth much if I > have to muck around in crontabs from a shell to make it work... And > since it should expose this functionality, you can actually schedule > things from your controllers, which you definitely would not be able > to do if you used regular cron. Not to mention that all of this > happens on the level python so it should automagically work for linux, > windows and mac and you could even mix them - develop on one and > deploy on the other. > > It also allows code to do it's own cleanup after the client is gone > (how about some database operations, user tracking stuff, session > flushing, perhaps even the final db commits/rollbacks ?). This can > actually improve user experience as the user won't wait for web2py/ > wsgi to end something that produces no output for the browser. > > Yarko: But why the additional server ? If you're contemplating web > services in such a manner, for me it would make more sense to make a > specialized application (like T2) and call the functions/modules/ > controllers of that app. I'm not too keen on introducing another > daemon, as I feel that is like running in circles - you change from > mod_proxy to mod_wsgi to do away with the external calls and then you > have to start an additional daemon that handles... well.. external > service calls. > > On Oct 9, 11:20 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > I think we are talking about something else here. "services" in this > > thread should be read more like "deamons". specifically programs that > > are triggered by events, run in background and are not connected to > > normal IO. > > > achipa wants the ability to start threads from within web2py to do > > database cleanup or other repeated tasks. > > > Massimo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
