Ian Bicking wrote:
Cool. I think this should mean integration with Paste would involve extending paste.server.make_app (which clearly exemplifies the switch-statement style that OO is supposed to avoid ;):
if conf.get('publish_quixote'): from qwip2 import QWIP2 app = conf['publish_quixote'] if isinstance(app, (str, unicode)): from paste.util import import_string app = import_string.eval_import(app) if not isinstance(app, QWIP2): app = QWIP2(app)
This should allow 'publish_quixote = "quixote.demo.mini_demo"' in the server.conf to load the demo. I won't be able to test this until this evening, but that's my theory.
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.
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.
Or is it to allow only a few details to be set by the user (host, port, server type)?
No, I want to avoid keeping it too simple, as it means lots of different config files strewn all over the place, probably unnecessarily exposing the underlying structure.
I'd say make server.py generic, and make the user set an 'application' variable with a WSGI-wrapped application, perhaps using helper classes from another module. That way people can use a different application type without having to hack it into server.py, and (for Quixote) can use this qwip or that qwip or anywhere a qwip-qwip without being constrained by the server.py assumptions.
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.
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. So I think the higher-level (more abstract) configuration is easier to maintain while changing implementations.
It is true that publish_dir (which was webkit_dir) loads specific middleware that Webware needs. I'm not sure how to resolve that... now that I think about it, maybe publish_dir should have stayed webkit_dir.
I do want these things to be pluggable at some point, but I'm not sure how to do that. Webware startup was slowed significantly because it spent time looking around for plugins, to the point it was not reasonable with CGI. (Paste is a little slow too for CGI, but I think that is still resolvable, but with generic plugins it would be harder to fix).
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.
He can wrap additional middleware functions around his application, but he can't override any of the system-chosen middleware. There's a tradeoff here between frameworks requiring certain services to function, vs allowing the user to switch implementations in and out, and (in Quixote's case) using services built into the Publisher vs in middleware.
There's also a question of who is doing the work. If it takes a little fiddling to swap middleware, when that's an uncommon sort of thing to need, then that's okay. For instance, if we have a really good session object, and someone wants to experiment with their own. In the end, if that person comes up with something good, there's a good chance we'll want to integrate it into the existing middleware.
I guess part of the idea is one of "user interface", where Paste is providing a kind of user interface to the underlying components. I don't want people to dig around in the code to do normal things under Paste, or have to provide alternate implementations to customize things. If you want to extend and improve Paste, sure, but not if you are just *using* Paste. It's not satisfying, and it's unlikely your modifications will go back to the community (at least that's my experience with that class of users).
I don't know for certain how this should work, but I'm just trying hard to avoid recipes; I want to encode that knowledge into the tools.
server.py can't expand to cover all these possibilities, nor will it necessarily have the best implementation for a third-party framework, so why not delegate those decisions to the config file (with plug-in helper classes perhaps)?
I agree as a flat Python file with lots of if statements server.py can't hold it all. But I want to give the naive approach a chance, where configuration remains simple and we have smart code that reads that configuration and puts stuff together. And I don't want to get too distracted by abstraction, as you can quickly create complicated dependency-finding code and all sorts of weird stuff that no one understands.
Is there a rule that config values have to be strings/numbers, or can they be perhaps a QWIP object? That would eliminate the need for 'publish_quixote'.
Configuration values from the command-line can only be strings, but in file they can be anything. With this recipe you could do "paste-server --publish-quixote=quixote.demo.mini_demo" but without that it would be infeasible.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Quixote-users mailing list [email protected] http://mail.mems-exchange.org/mailman/listinfo/quixote-users
