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