On Wednesday, 22 June 2016 23:58:47 UTC-4, Anthony wrote:
>
>
> The current idea of Anthony is to directly use wsgihandler as the wrapper
>>
>
> No, the "wrapper" would be a callable object, and it can be defined 
> anywhere. wsgihandler.py is just the entry point -- you could import the 
> wrapper in wsgihandler.py and then expose it to the web server (as in the 
> built-in version of wsgihandler.py).
>

OK, this is different from what I first understood. In other words, the 
wrapper is gluon.main.wsgibase (but we can rename it in wsgihandler.py). 
Not having understood it, I just suggested the same. In fact, I was 
thinking that we would allow different wrappers for different requests, 
associated with different applications.  So, gluon.main.wsgibase (what is 
exposed in wsgihandler.py) would not be the wrapper, but would only map the 
requests to different wrappers.  

>
> However, a more important issue is that the installer needs access to the 
>> HTTP server configuration at a deep level, if he wants to choose the 
>> location of the wrapper.
>>
>
> No, the installer would need the same level of access to the server 
> configuration as usual. The installer is going to have to set up some kind 
> of handler for the web server no matter what.
>


Yes, this is what I was thinking too. So, I rediscovered what you had 
already proposed. 
 

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to