[Zope-dev] package dependency refactoring progress report

[Martijn Faassen]

Hey Shane,

Shane Hathaway wrote:
> Shane Hathaway wrote:
>> Martijn Faassen wrote:
>>> So, the only dependency cycles left in zope.app.publisher are these:
>>>
>>> zope.app.publisher <--> zope.app.publication <--> zope.app.http
>> I fixed those tonight.  On the trunk, there are no longer any 
>> dependencies between zope.app.publisher, zope.app.publication, and 
>> zope.app.http, except testing dependencies.
> 
> I should take a moment to describe the different purposes of these 
> packages as I see them now.  Conceptually, they are really quite 
> independent.

Thanks for doing this analysis, and considering improved naming. I think 
good naming is very important, and it will help get this functionality 
out of the 'zope.app' ghetto.

> - zope.app.publisher: A library of ZCML directives for configuring 
> views.  Also provides generic view classes.  A better name for this 
> package might be "zope.basicviews".  A lot of packages depend on this.

I'm not sure 'basic' needs to be in there. Do we have anything less basic?

What about simply calling it zope.view? (I don't like the plural in 
package names either generally)

> - zope.app.publication: Provides IPublication implementations and a 
> mechanism/registry for choosing a different publication class for each 
> request.  Most packages should not depend on this.  A better name might 
> be "zope.publicationregistry".

I'm fine with this. I was considering 'zope.publication', but we already 
have 'zope.publisher' so that'd get very confusing again, something we 
should avoid.

> - zope.app.http: Provides generic views that translate HTTP verbs like 
> PUT, DELETE, and OPTIONS into map operations.  The idea is clever, but 
> not everyone needs a REST-style API.  A better name might be 
> "zope.httpverbs".

Even though I don't really like the plural, I think 'zope.http' would 
promise a bit too much, so 'zope.httpverbs' sound better.

So if we get some consensus about this, we need volunteers that can help 
move the code over to these new packages and leave backwards compatible 
imports in the old places. Is there anything in these packages we can 
safely leave behind do you think? (ZMI related, perhaps?)

Regards,

Martijn