[Zope3-dev] directory hierarchy proposal

[Martijn Faassen]

Gary Poster wrote:
[snip]
> 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?

Those are good points. Though the idea is that actual extensions to
Zope 3 are going to sit in a totally separate hierarchy anyway. And
that you aren't going to get away with substracting from the core code;
this is why it's the core. You are making distribution arguments, but
you're not going to commonly distribute Zope.App stuff separately. But
basically the idea is Zope 3 will be distributed as a whole (at least
Zope.App).

Then again, I'm not sure myself. Some more discussion may be necessary
here.

> 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 interfaces won't be in the hub.py module; they'll either be in
ihub.py or interfaces.py. The module size of hub.py is quite manageable
then; we tested this and the total amount of lines shrank quite a bit
as we could eliminate some duplicate imports and lots of license 
text. :)

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

We're still discussing the possible need for a completely separate
interface hierachy, actually. Some of the arguments concerning a view
hierarchy apply to interfaces as well.. 

> >>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 don't know what PathSubscriber is, so I can't answer that. Implementations
of objects that allow through the web code would be in .software. Just
like  zope.app.service contains the implementation of services (but not
the services themselves), and zope.app.content contains the implementation
of content objects (but not the content objects themselves) zope.app.software
would contain the implementation of ZODB-based software, but not the
software itself. 

Regards,

Martijn