| « Dejavu has a new home | The medusa called autoreload » |
Eat less, exercise more
10/06/05
Eat less, exercise more
Dave Warnock muses:
I am not about to argue that [TurboGears and Subway] should merge, instead I feel they can improve most by making sure that they each stay thin putting all the improvements they can back into the components eg CherryPy (which they both have been doing) and into the deployment elements (setuptools and paste).
That's a good point, and I think it's at the heart of what CherryPy is trying to be: non-fattening. So there's definitely going to be some pushback from CherryPy itself trying to "stay thin".
I often say that CherryPy is not a "web framework"; it is an "HTTP framework". That is, it doesn't try to provide tools for every facet of web development. Instead, it concentrates on wrapping HTTP up in a Pythonic way.
IMO, working to stay thin is an important factor in getting CherryPy "more exercise": it gets used in more meta/mega-frameworks like Subway and TurboGears precisely because it hasn't gobbled up every good idea, just because it's web-related, or even just because it's Python. For example, CherryPy 2.1 is deprecating the Aspect module that was in 2.0, because it isn't related to the HTTP-focus of CherryPy.
David goes on:
Another project that is the next level down from these frameworks but that is also moving fast is Quixote, I feel the differences between Quixote and CherryPy are also becoming smaller (shown by the recent blog posts on Python Web Controllers). Whether they could ever merge is a different matter. Probably not possible (or even desireable) for the moment.
I would have to agree. There's a decisive difference in architectural style between CherryPy and Quixote. That doesn't mean there aren't components that are common to each, and there are certainly some which are unique to each which deserve to be ported! If the Quixote coders are willing to give up all the method names starting with set_ and get_ we're ready to have a conversation about merging. 
5 comments
I agree that CherryPy also needs to stay thin. The things I was talking about were to make sure that TurboGears does not do internally things that the CherryPy team would want to be part of CherryPy. For example at the moment there is
http://www.cherrypy.org/ticket/145 "Running multiple apps in one process"
which is something coming from Paste and TurboGears but seems like it should be part of CherryPy for it do it's own purpose properly. We don't want to make it harder to stay up-to-date with CherryPy by putting too much in TurboGear, but equally we don't want to add to CherryPy stuff that is TurboGear or Subway specific.
Thats a balance for us all to live with in all these projects, it's what keeps it fun ;-)
Dave
Having concise, easily understood parts make up the whole is something that appeals greatly to me. I've been working on my own little "mega" framework or whatever the word is for them, and the thing that stuck me is that you do make some gains by having some of the other parts included.
I was originally looking to see if I could use CherryPy with Myghty as the template language, but some of the abilities I gained when using Myghty for the controller aspect as well couldn't be attained (AFAIK) without a more tightly knit connection. Take this somewhat common thing thats done in Rails:
"live", :action => "status" %>
We're sticking the full HTML output of what is essentially another request, and putting it into the current page. I can do this if I use Myghty for both Controller and View since Myghty treats Controller actions/methods as components that can be included.
No clue how this would be possible using Cheetah, or Kid, or something where the template language doesn't know about the Controller that called it. So far in my Rails experience, Active Record is very decoupled from the rest of Rails. I've actually used Active Record by itself, its quite easy (Though I prefer SQLObject). However, the Controller/View code in Rails is tied much closer.
Definite advantages and drawbacks to both approaches.
By the way, this is what that code fragment should've looked like:
"live", :action => "status" %>
"There's a decisive difference in architectural style between CherryPy and Quixote."
Could you outline for someone familiar with Quixote what the difference is.
"Could you outline for someone familiar with Quixote what the difference is [in architectural style between CherryPy and Quixote]."
Sure. Here are some of them that I see:
1. Quixote requires a separate Publisher object, to which you pass your handler Root. CherryPy asks you to attach handlers to the cherrypy.root object.
2. Quixote is single-threaded by default. CherryPy is multi-threaded by default (and uses WSGI by default, to boot).
3. Quixote expects you to subclass a core class as your Root (is it required? you at least need q_traverse, I think). CherryPy expects the opposite (although it's permitted--see Subway's controller.Controller for example).
4. Quixote passes a request object to page handlers; if you want CGI params, you call request.get_field(name). CherryPy passes CGI params as **kwargs to page handlers; if you want other request data, you use cherrypy.request.xxxx.
5. Quixote has a "get" fetish IMO--get_user, get_environ, get_field... CherryPy tends to use "var = object.data" where Quixote users write "var = object.get_data()".
6. Quixote includes PTL. CherryPy is templating-agnostic.
7. Quixote mixes encoding, gzipping, the Expires header, javscript-inside-forms (!) and many other optional features into the core. CherryPy shoves those things into filters in its standard library.
8. CherryPy allows streaming output to any HTTP server. Quixote only provides it to medusa and twisted servers by default.
9. CherryPy has a comprehensive test suite. If Quixote has one, they've decided not to ship it with the distro.
10. Quixote's package architecture seems to be based on module/subpackage size. That is, if a feature has enough lines of code, it will get its own module, or subfolder. CherryPy has a separate /lib folder for app-developer imports (see http://www.cherrypy.org/wiki/PackageStrategy).
I'm sure there are others, and there are probably some errors in my understanding of Quixote. But those are some differences I see at the moment.
Comment feed for this postLeave a comment
