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

[Dan Korostelev]

2009/8/22 Shane Hathaway <shane at hathawaymix.org>:
> Hi Dan,
>
> I'll provide feedback for a few parts of your proposal.
Thanks

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

That's a good point. After a quick look, it seems to be easy to move
xmlrpc-related things from zope.publisher and zope.app.publisher to
new zope.xmlrpc package. One problem is how to make BBB imports then.
It doesn't look good to me to make zope.publisher dependent on
zope.xmlrpc for xmlrpc stuff, but moving things without BBB imports
will break applications that currently uses zope.publisher xmlrpc. One
option is to use the notorious "extra" dependencies, but that needs to
be discussed. Other options is to start a big refactoring of
zope.publisher, but that is a thing I didn't want to do right now, so
the third option is to leave these things until zope.publisher
refactoring. ;-)

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

That's true, but see my reply to Fabio Tranchitella on this topic. :-)

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

Okay then, let's leave the class hierarchy as is :-)


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

Then, there's the same option and the same problem as one for XMLRPC,
described above. :-)


-- 
WBR, Dan Korostelev