A while ago I posted a roadmap for Quixote 1.0. Here's a Wiki-editable version of it.
=================================================
For a while the only thing preventing us from stamping the magic 1.0 version number on Quixote was a vague desire to refactor the quixote.publish.Publisher class. Yesterday David, Neil, and I sat down to actually discuss what to do.
Publisher is a large bear of a class, around 275 lines of code. When you want to connect Quixote to a new infrastructure such as Medusa, or SCGI, or Twisted, you have to subclass Publisher to customize it. This used to be very messy, but I cleaned things up a bit writing medusa_http.py. The need to subclass still makes the required driver script for a Quixote application a bit more complicated than it should be.
Publisher does a number of things, such as logging, creating request objects, and traversing the namespace based on the URL. The goal for the future version of Publisher is to let the user specify objects that will handle these tasks instead of having to subclass. Session management will also be done by an object.
For example, the driver for Quixote-via-CGI might look something like:
logger = LoggingObject()
publisher = Publisher('application.ui',
log = logger,
request = CGIRequester(),
# default session manager does nothing
)
publisher.run()(I just came up with the name 'Requester' for the class; it may be something different in the actual 1.0 code.)
Publisher.run() will then do something like:
def run (self):
# Loop ends when there are no more requests
for request in self.requester:
self.do_request(request)(Again, details subject to change...)
The application can be changed to work with SCGI by using SCGIRequester instead of CGIRequester. You can turn off logging by specifying a NullLogger instance that does nothing. You can supply your own session manager.
Note that the traversal process is not on the list of customizable things. Therefore, one of my first jobs will be to remove that logic from the Publisher class. I doubt anyone is overriding these methods to customize the traversal process, so this change seems safe for 0.6.
It's not yet clear how to do this and keep existing code running, but we'll certainly try. Do any of you have your own subclasses of Publisher? If so, I'd like to know about them and, if possible, get copies of them.
Plan of action for 1.0:
- Factor out the logging and request-building interfaces from Publisher.
Factor out the session management interface from SessionPublisher. SessionPublisher will become a near-trivial subclass of Publisher; Publisher will default to using a null session manager while SessionPublisher will default to the current in-memory session storage.
Include NullLogger, NullSessionManager, and sensible default implementations. Include CGIRequester, SCGIRequester, FastCGIRequester.
- Release 1.0, and then hopefully we can leave it alone.
Other 1.0-relevant issues
- Quixote's support for Unicode output needs to be specified and tested.
- Sub-item: we should probably add convenience methods to HTTPRequest to get the agent's language preference.
- Add support for Basic and Digest authentication.
Comments
Perhaps the Web Container discussions on Web-SIG could factor into this somehow. Supporting things like SCGI, Twisted, and CGI (as well as mod_python, FastCGI, and others) alongside a single publisher is one of the main goals of that interface. -- Ian Bicking