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] 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] <javascript:>> 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] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>.
> Visit this group at http://groups.google.com/group/modwsgi 
> <http://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout 
> <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] 
> <mailto:[email protected]>.
> To post to this group, send email to [email protected] 
> <mailto:[email protected]>.
> Visit this group at http://groups.google.com/group/modwsgi 
> <http://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout 
> <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.

Reply via email to