On 06/20/2016 12:47 PM, Doug Hellmann wrote:
Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400:
On 06/17/2016 11:23 AM, Sylvain Bauza wrote:
+1000 yes to that. Now the devil could be in the details, in particular
how we implement the WSGI server, the corresponding WSGI app and the
associated routing, and that's exactly the problem below.
We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi,
etc) is a bad thing.
I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?
In the review, you explain why you don't trust Routes and I respect
that. That said, are those issues logged as real problems for our API
consumers, which are mostly client libraries that we own and other
projects we know, like Horizon ?
If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?
For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.
Best,
-jay
It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.
WSGI frameworks shouldn't be handling transactions, IMHO. That's a ba d
coupling problem.
And no, I don't believe this will result in a new framework being
created, precisely for the reason that no such framework is needed...
Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?
As I said, I'm OK with using Routes since it's already in g-r, but I
just don't see a need for a WSGI framework, especially one that includes
things like a WSGI server.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
