[Zope3-dev] What is Core?

[Jeffrey P Shell]

On Feb 8, 2004, at 2:28 AM, Michael Haubenwallner wrote:

> Stephan Richter wrote:
>> On Saturday 07 February 2004 18:24, Jim Fulton wrote:
>>> One possibility is to say that 1.0 (perhaps a different designation
>>> would be better) is really for those people who are already 
>>> delivering
>>> Zope 3 apps.  It emphasizes the things that work pretty well now,
>>> meaning core services and file-system-based developmen
>> Yes, I agree with that based on your previous message. I can always 
>> make a experimental TTW-enabled release, like "1.0+TTW" for people 
>> who want to try it and give feedback. Zope 3 1.0 will get a lot of 
>> attention, and I would love to use some of this momentum to get TTW 
>> development feedback. On the other hand I do not want to make the 
>> main release messy, late and unstable, so that people will look at it 
>> and say: What the hell is this?
>>
>
> Would it make sense to remove the TTW-management-interface from the 
> 'core' and into a product ? Could this product be used as an example 
> of how to write management products for zope3 ?

Alright - what is 'core'?  I remember typing up this question, but I 
don't know if I ever sent it.

I thought core was everything *but* zope.app.  zope.component, 
zope.publisher, etc - that was the core core.  Is that stuff now 
'sub-core?' (which is kindof hard to do ;).  Or is it the meta-core?

I just hear a lot of people batting the term 'core' around an awful lot 
these days.  Usually in terms of "maybe that shouldn't be in the core."

And I hope will also help us avoid the 'man, we really need to bust up 
zope.products' conversation if everything from 'zope.app' ends up in 
there.

Maybe 'ttw' should not necessarily be in 'zope.products', but as 
'zope.ttw'.  This changes some of the definitions of what those top 
level zope.* packages should be, but I think that's been shifting 
anyways.

Or maybe it's really time to start looking at component packaging, 
distribution, and installation issues, so that elements that could very 
well be part of the so-called 'core' can be distributed and installed 
on their own until they become part of the core.  Component Management 
is a pretty significant part of many component architectures, which 
includes installation as well as configuration.  We've got the 
configuration bit pretty much down, it seems, but adding and removing 
the actual software bits seems to be another matter.

I guess that's been one of the benefits of the magical 'Products' 
package of Zope 2.  You can refer to 'Products.PythonScripts', which is 
installed in /usr/local/zope/2.6.1/lib/python/Products; and refer to 
Products.SuperTemplates, which is installed in 
/home/jshell/projects/cust1/Products.

I don't like how this was used to install and deal with third party 
products - I'd prefer to keep our packages in our own top namespace (ie 
'bottlerocket.commerce' or 'bottlerocket.ticketing'), and I like that 
Zope 3 supports this (now that 'path' configuration is in the ZConfig 
setup).  However, I do like that Products.* was a system that allowed 
for packages like Page Templates to be distributed individually until 
they became part of the common distribution - in a way that was 
forwards compatible with their acceptance.