Sideboard happens to use CherryPy as its server component. This is unlikely to change anytime soon, for the following reasons:
Sideboard relies heavily on our ability to run background threads in the same process. So while we could theoretically move to another Python web server, it would need to have the same approach as CherryPy.
We really want Django to be able to run in a Sideboard plugin; that means that whatever web server we use must be a fully WSGI-compliant web server.
We currently use the CherryPy "tool" interface for a couple of things; theoretically this could all be rewritten to use WSGI middleware, but that would take a lot of effort.
CherryPy configuration is part of Sideboard's main config; we'd need to change this as well
This is part of a larger discussion that we've had about whether it's okay for us to be intrinsically be tied to CherryPy. #33 is an example of a ticket which is about working around the limitations of CherryPy (technically it's working around the limitations of ws4py's CherryPy plugin, but still).
One middle ground between "just rely on CherryPy" and "rip out CherryPy and replace it with Tornado" (which we might eventually do, for performance reasons) is to have the basic CherryPy interactions wrapped with things in sideboard.lib. For example, instead of saying cherrypy.tree.mount() we could just say sideboard.lib.mount() and instead of raising cherrypy.HTTPRedirect we could have them raise sideboard.lib.HTTPRedirect, etc.
I'd like to take a closer look at Tornado to see how similar it is to CherryPy in terms of API. I know that you can host WSGI apps with it, and you can do the "your web server is just some of the threads in your Python process" thing with it, so it's a possible replacement that probably is much more performant.
Sideboard happens to use CherryPy as its server component. This is unlikely to change anytime soon, for the following reasons:
This is part of a larger discussion that we've had about whether it's okay for us to be intrinsically be tied to CherryPy. #33 is an example of a ticket which is about working around the limitations of CherryPy (technically it's working around the limitations of ws4py's CherryPy plugin, but still).
One middle ground between "just rely on CherryPy" and "rip out CherryPy and replace it with Tornado" (which we might eventually do, for performance reasons) is to have the basic CherryPy interactions wrapped with things in
sideboard.lib. For example, instead of sayingcherrypy.tree.mount()we could just saysideboard.lib.mount()and instead of raisingcherrypy.HTTPRedirectwe could have them raisesideboard.lib.HTTPRedirect, etc.I'd like to take a closer look at Tornado to see how similar it is to CherryPy in terms of API. I know that you can host WSGI apps with it, and you can do the "your web server is just some of the threads in your Python process" thing with it, so it's a possible replacement that probably is much more performant.