Hello Graham, Thank you for your attention. No problem: I knew you were taking some holidays. Hope you enjoyed them thoroughly. Actually Jason is quite busy for the moment but he promised he will let me know when he gets a bit of free time to call me over Skype. This should happen within a week or two.
In the mean time I made quite some progress but wouldn't boast I'm using mod_wsgi in the most efficient fashion. What I have currently devised for my exercise is following: Each server script called by a form action, creates an instance of a WSGI application class that contains: - an __init__ function receiving the name of the script initiating the instance - a __call__ function of the sort application(environ, start_response) - a passRequest function that passes the request to the instanciating script (known via the __init__ argument) and provides the callback name, so the script knows where to provide its answer. In other words the server script creates an instance, which in turn is called by mod_wsgi, then passes the request to the script that does its processing; when done the script returns the answer to the instance that calls back mod_wsgi. So there is a one-to-one dialog between the server script and the called instance it created. I haven't yet deepened my exercise to evaluate how strong or fragile this construction is but so far, it works well. I'll keep you posted as soon as I can speak with Jason. Kind regards, René On Tuesday, September 29, 2015 at 12:48:08 PM UTC+2, Graham Dumpleton wrote: > > Hi René > > Was Jason able to answer you questions adequately? > > Sorry for not replying at the time but I was stuck on a cruise ship with > no Internet at the time. > > Graham > > > On 7 Sep 2015, at 1:50 pm, [email protected] <javascript:> wrote: > > Hello Jason, > Thank you for your offer. > I'll contact you then off list. > Regards, > René > > On Saturday, September 5, 2015 at 3:09:51 AM UTC+2, Jason Garber wrote: >> >> Hi René, >> >> There are thousands of ways to handle this. We use a really simple but >> effective approach with nginx and apache doing what they both do best. If >> you want - I can explain it in detail (off list) to help you understand >> these things better. >> >> Let me know. >> Jason >> On Sep 4, 2015 11:04 AM, <[email protected]> wrote: >> >>> Dear All, >>> >>> I'm not yet intimate with WSGI and I wish to know what is the Best >>> Practice to connect to Python applications. >>> >>> Let me set the scene: >>> >>> 1) the mod_wsgi module is loaded with the hhttp server (Apache2), is >>> active and working. >>> >>> 2) The configuration is simple: >>> >>> WSGIScriptAlias /core/ /home/rse/core/ >>> >>> <Directory /home/rse/core> >>> AllowOverride None >>> SetHandler wsgi-script >>> Options -MultiViews +SymLinksIfOwnerMatch >>> Require all granted >>> </Directory> >>> >>> WSGIDaemonProcess rseIMS user=rse group=rse processes=1 threads=16 >>> python-path=/home/rse/core >>> WSGIProcessGroup rseIMS >>> WSGIImportScript /home/rse/core/imsStart.py process-group=rseIMS >>> application-group=rseIMS >>> WSGICallableObject imsApp >>> >>> rse/rse is my user/group id on Linux and ims or IMS is a generic name. My >>> Python >>> >>> applications have thus names like imsConfig.py, imsUtil.py, >>> imsDatabases.py, etc ... and are packaged under the /home/rse/core >>> directory or sub-directories. >>> >>> The alternative, as I understand it, is twofold: >>> >>> CASE A: >>> ------------- >>> Because all my imsXYZ.py applications are under the the /home/rse/core >>> directory, Apache2+mod-wsgi know that they must be handled by Python. So, >>> when the environment dictionary, contains: >>> >>> mod_wsgi.callable_object: imsApp >>> mod_wsgi.script_name: /core/imsExample.py >>> >>> the "Python daemon" knows that it must execute imsExample.py, and the >>> latter better knows about a function or class named imsApp, e.g. through >>> the statement `from core.imsWSGI import imsApp`, assuming that imsWSGI.py >>> contains the function or class definition of imsApp. By calling imsApp my >>> application imsExample will know what to do by investigating the content of >>> `wsgi.input` and after finishing its processing will pass its response back >>> to imsApp. For instance the imsApp can have two methods: passRequest and >>> getResponse for exchanging the request/response between imsApp and >>> imsExample or any imsXYZ application. >>> >>> CASE B: >>> ------- >>> Because imsApp is the obliged gateway between Apache2+mod_wsgi and my >>> applications, I could modify my webpages so that I would always have: >>> >>> mod_wsgi.callable_object: imsApp >>> mod_wsgi.script_name: /core/imsWSGI.py >>> >>> and put `Example` as part of the `wsgi.input` so that by executing >>> imsWSGI.py, it would be easy to know that imsExample (whatever it would be: >>> function, class,...) must be called to process the other meaningful parts >>> contained in `wsgi.input` >>> >>> >>> >>> My understanding of the alternative is summarized as follows: >>> >>> My applications can be called either via the script-name or the callable >>> object. >>> Both must be present because otherwise I would have one huge monolithic >>> application. >>> >>> My question is threefold: >>> 1) Is my understanding of CASE A and CASE B correct ? >>> 2) Are these two cases the only possible ones (I'm not envisaging static >>> pages >>> that could be delivered by NGINX for instance in front of Apache, >>> or have a separate directory for serving CGI-type Python scripts) ? >>> 3) If the answers to 1) and 2) are YES, YES, what is the Best Practice: A >>> or B ? >>> >>> Many thanks in advance, >>> René >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >>> >> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
