[Zope-dev] Proposal: zope.app.publisher refactoring

[Shane Hathaway]

Hi Dan,

I'll provide feedback for a few parts of your proposal.

Dan Korostelev wrote:
> xmlprc - move the IXMLRPCView interface and XMLRPCView base class to
> zope.publisher as a counterpart to zope.publisher.browser.BrowserView.
> Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to
> new "zope.xmlrpcview" package. Also I'd merge MethodTraverser with
> MethodPublisher to make it easier to understand and to decrease number
> of entities :)

Few developers care about XML-RPC these days.  Most web developers are 
now working with REST, JSON, and other similar stuff.  It's probably 
best to move all XML-RPC artifacts, including those in zope.publisher, 
to a single package, so that most developers can safely ignore the 
XML-RPC code.

> IXMLRPCPublisher adapters for zope.container - move them to
> zope.container. The IBrowserPublisher adapters that are already there,
> so it won't make things worser. The zope.container package may be
> refactored later to break dependency on zope.publisher though.

You need Jim Fulton's input on this.  I think his latest opinion is that 
zope.container should have nothing to do with publishing.

> IHTTPView and IFTPView interfaces - move that into zope.publisher as a
> counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a
> subclass of IHTTPView?)

In zope.app land, sometimes IHTTP* really means INonBrowser*.  In other 
words, sometimes people want to define views just for HTTP ports not 
intended for web browsers.

> IFTPDirectoryPublisher interface - not sure what's this and where is
> it used. Probably should be moved to zope.publisher.interfaces.ftp as
> well.

FTP is in the same boat as XML-RPC.  Today, very few developers care to 
provide a dynamic FTP view of anything.  WebDAV usually wins over FTP 
because adding SSL to WebDAV is easy.  All FTP artifacts should move to 
a separate package.

> That's all for now. I'd like to see some
> comments/propositions/objections before I start. Also, maybe there are
> more beautiful names for new packages?

The names you proposed seem ok.

Shane