A.M. Kuchling wrote:

> On Fri, Jan 09, 2004 at 04:26:26PM -0500, Graham Fawcett wrote:
>
>>conference? And what would you like to work on? I recall some talk of a
>>refactored Publisher some time ago; are there other such projects on the
>>back-burners?
>
> There's the 1.0 roadmap I posted some time ago; I should dust it off and try
> to get working on it again.  That might be a good sprint candidate.  Can
> anyone think of other useful Quixote projects?  Is there any form framework
> stuff that would need doing? Holding a BoF is worthwhile, too.


For dissucssion, I hunted down the 1.0 roadmap (Mar 13, 2003):

http://article.gmane.org/gmane.comp.web.quixote.user/1306

excerpted in full, below. The brief ensuing discussion concerned the
Publisher proposal, forms and PTL dependencies, and customizable URL
traversal.

Perhaps the Web Container Interface proposed on Web-SIG might have
frozen by March. If so, implementing the WCI might be a worthy (and
relatively easy) 1.0 feature.

-- G


Long ago, A.M. Kuchling wrote:

> 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"