[Zope3-dev] Publisher test harness for new protocol development

[Shane Hathaway]

Jeff Kowalczyk wrote:
> [Stephan] (Zope as a Universal Network Conduit) is my dream too. Please,
> please, please help writing servers for Zope 3. If you like, I can
> create a branch tonight, so you can look at some of the new development
> in VFS and FTP stuff.
> 
> [Jeff] If the server framework
> http://cvs.zope.org/Zope3/lib/python/Zope/Publisher/ is the replacement
> for Medusa in Zope3, there probably needs to be some entry-point for
> people who are interested in working on a protocol, but are unfamiliar
> of all the details needed to interact with Zope3 at its present
> development stage. Something that makes experimenting with your new
> framework as approachable as
> http://www.nightmare.com/medusa/programming.html would be immensely
> helpful.

The architecture is a little more modular than you realize.  The 
replacement for Medusa is actually in lib/python/Zope/Server.  The 
publisher in Zope/Publisher receives a request from the server and gives 
a response.  You can actually plug in a different server; for example, 
Itamar has successfully plugged in Twisted's HTTP server (IIRC).

> But in lieu of documentation, which might be premature at this point,
> could one of you who are very familiar with the new framework create a
> protocol development test harness for it? This could be a combination of
> a few debugging support classes for running Publisher separately from
> Zope3, and some very explicit, non-zope-specific instructions for
> getting a telnet (or logged) view of a new MyProtocol.py conversation up
> and running on Windows and Linux platforms. 
> 
> If it is possible, it would probably make the process easiest if the end
> point of a protocol's handler when run in the test harness was just a
> reflection string of the method and parameters that would call into
> Zope3 objects if run normally. The protocol developer could override
> response methods to continue a conversation with a client that expected
> folder names, for example. You'd be able to observe what a given client
> program would call on Zope in a given situation, to compare it with the
> relevant RFC document.
> 
> It would lower the entry barriers for people new to protocol programming
> and/or Zope(3) core development. We'll get support for more protocols
> out of it. If Zope3 is going to encourage support for many protocols on
> a new and as-yet undocumented framework, a self-contained protocol
> conversation and debugging technique maintained as part of the /test
> suite will be something everyone will benefit from long after the
> initial Zope3 release.

Well, that is a noble idea, but I don't know if it's possible.  Every 
protocol is quite different and serves different needs.

I would be interested in seeing if Twisted, or certain Twisted modules, 
can be relicensed under ZPL.  It has dozens of protocol implementations.

Shane