[Zope3-dev] directory hierarchy proposal

[Gary Poster]

Martijn Faassen wrote:
> Gary Poster wrote:

>>"Don't shy away from using acronyms in package/module names."
...
>>-1 on this one, or at least elaborate.

> What about 'don't shy away from using well-known acronyms'? I've tried
> to follow this.

Sounds good to me.  +1.

>>I did not like seeing zope/app/services/event.py and so on.  I think an 
>>important elaboration of this is that packages that cannot have 
>>arbitrary parts added in and removed are ok to compress as the quoted 
>>recommendation describes, but that "services", and to a lesser degree 
>>"content", should be allowed to have smaller distinct packages for the 
>>convenience of being able to drop things in and pull things out.
> 
> 
> Like plugins? I'm not sure about how it would work for zope.app.service;
> perhaps someone else who knows more about this can answer. As for
> zope.app.content I don't think that many 'drop in' pieces can exist,
> especially as views are also supposed to be moving away.

I'll explain below.

>>Discussion points:
>>
>>  * reading the code, I'm willing to go to one interfaces.py for a 
>>given subsystem (i.e. service), but I don't want to go to a service 
>>interfaces.py to muck through *all* the service interfaces in there. 
>>These are completely different components!
> 
> That's a good point. We discussed the ability to create ifoo.py files
> for separate interface files for this purpose.

That might be ok.  I'd lean towards another directory, but I realize 
that's a "backwards" idea at this point.

>>  * a number of the service packages contain a decent amount of code 
>>and/or interfaces, and the majority of them have no "global" counterpart 
>>in which to store extra interfaces (as event does).  Being able to group 
>>them in a directory is good.
> 
> Sure, I don't think this proposal forces you to use a module; just encourages
> to stick to modules to try to keep the tree from deepening rapidly.

OK, good.  Wasn't sure about the proposal's rigidity about that.

>>  * I feel particularly strongly about this for the two services with 
>>which I am most familiar, the object hub and the event service.  I'll 
>>elaborate if requested.
> 
> Please do; what is the kind of stuff you'd like to be able to drop
> in that you can't drop into a module file?

I'm not talking about plugins; I'm talking about new content types and 
new services included in a Zope 3 distribution.  If you want to add in a 
new content type in a release, why should you have to modify the 
interfaces.py of content?  why can't we just drop in a new folder, or at 
least some new files without modifying any others?  If you want to 
remove (hypothetically!) the DTML file from a distribution, why should 
that affect files that contain information about other content?

A similar argument can be made for services.  The ObjectHub package 
contains a lot if interfaces, and the LocalEventService package contains 
a lot of code, so I might argue that they would make reasonable 
candidates for a package rather than a module.

The two points you made above--separating out the interfaces, in one 
case, and having the freedom to use a package when you think it makes 
more sense, in the other--do address my concerns, if they are adopted.

>>Can we agree on that distinction, or is there a similar compromise that 
>>might work?
> 
>>what is zope.app.software?  The replacement for ZopeProducts?  That's 
>>fine, but it wasn't crystal clear to me.
> 
> No, its intent is to contain stuff that is going to be in the services,
> but is software, not the service itself. Things like TTW page templates,
> TTW modules, etc.

You mean like PathSubscriber in the event service?  Things that are used 
with a service but are not necessarily part of the service itself?  If 
that's what you mean, I prefer to have them with the service.  I also 
agree with RDM that this name isn't really clear.

>>---
>>
>>I guess the whole magical zcml ending "." thing that duplicates the last 
>>name until it resolves into a class can now go the way of the dinosaur? 
>> I didn't describe that very well: I'm trying to describe 
>>"Zope.Events.GlobalEventService." resolving to 
>>"Zope.Events.GlobalEventService.GlobalEventService" and so on.  We can 
>>get rid of that now?  Or is that still useful somehow?
> 
> 
> Not useful anymore; it was battling a symptom and we're trying to 
> tackle the root cause now. :)

Agreed.  Good stuff.

Thanks

Gary