durusmail: quixote-users: Plans for Quixote 1.0
Plans for Quixote 1.0
2003-03-13
2003-03-13
2003-03-13
2003-03-13
2003-03-13
2003-03-13
2003-03-13
2003-03-13
2003-03-14
Plans for Quixote 1.0
Andrew Kuchling
2003-03-13
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 0.6b4:

   * Factor traverse_url() and get_component() out of the Publisher
     class.  (Mostly done at this writing; I need to check why
     _q_exception_handler doesn't seem to be working.)

   * Release 0.6b4 very soon -- today, tomorrow?  This will then
     become 0.6final.  (Really, this time.  Hey, stop laughing!)

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.

I'd like to see 1.0 done soon, perhaps in time for PyCon, but we'll
see how it goes.  Watch the -checkins list to follow the activity.

Comments welcome.

--amk                                                    (www.amk.ca)
I never think twice about anything; takes too much time.
      -- Sanders, in "Kinda"

reply