Ian Bicking wrote: >> What is the purpose of Paste's config file? Is it so the user can link >> his application to the webserver and middleware of his choice, and >> configure everything regarding the application and its environment? > > Ideally, yes. However, for typical tasks it shouldn't get too > complicated. I'm trying to avoid configuration recipes -- I'd rather > hard code recipes into particular keys than document them, because it's > a much more pleasant user experience. > > My expectation is that as more features get put into Paste (or, more > generally, into generic middleware), that some of this will change. But > I'd rather hard code some things now and figure out what works when we > see the actual problem.
I'm happy as long as 'publish_app' is supported. > To configure middleware, I expect the middleware to look in > environ['paste.config'] and pull out specific values. But you're right, > this doesn't allow you to *create* middleware. Not create middleware, but specify a chain of middleware to be instantiated and assembled. Although given that custom middleware may have custom constructor arguments, maybe it's best to tell people with custom middleware needs to use 'publish_app'. > Right now you could do (in server.conf): > > from qwip2 import QWIP2 > import quixote.demo.mini_demo > publish_app = QWIP2(quixote.demo.mini_demo) > > I don't think that's very pretty, but it's allowed for. In Quixote 2 that's: from qwip2 import QWIP2 from quixote import demo #from quixote.demo import mini_demo as demo #from quixote.demo import altdemo as demo publish_app = QWIP2(demo.create_publisher) It's close to what Quixe'ers are used to doing, and is the most flexible. But if you want to automate some of those steps with 'quixote_app' or 'quixote_dir', that's fine. >> There's also middleware. The current Quixote handles its own sessions, >> etc. But soon there will be alternate Quixote implementation(s) with >> these factored out to middleware, or borrowing middleware from Paste or >> other sources. Currently server.py loads a certain stack of middleware >> for Webware applications, and the user isn't allowed to choose. > > That is true. However, if Quixote factors out some of that middleware > "publish_quixote" can still work just fine, even though the > implementation may change. Not quite. The examples above use a preconfigured Publisher with a preconfigured Directory. People probably won't want to customize QWIP so 'quixote_app' is fine. But if people have a raw Directory or 'namespace.string' for 'quixote_dir', you have to choose your default Publisher. But configuring the Publisher is where people choose which Publisher (sub)class to use, whether to enable built-in services that duplicate their custom middleware, what kind of session persistence mechanism to use, etc. So 'quixote_dir' is only useful in simple or default situations. > Another option is to rely more on paste-setup, and expect it to write a > little stub to some file in the root of the application, and include > that file into the configuration. That would hide some of the > boilerplate from users, while putting all the pluggability into the file > setup which isn't done at runtime. I wasn't planning to use paste-setup but to create my own directories. Perhaps later we can come up with a pattern suitable for paste-setup --template=quixote . _______________________________________________ Quixote-users mailing list [email protected] http://mail.mems-exchange.org/mailman/listinfo/quixote-users
