[Zope3-dev] What is Core?

[Jim Fulton]

Jeffrey P Shell wrote:
> 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 doubt that people are using this word consistently.  In fact,
it is often used as an adjective. In other words, it's meaning
is often relative to the context it's used in.

> 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 think of these as core in the sense that they are required to run the
zope application server.  But, zope.app is also core.  Things being lifted
out of zope.app into zope.products are things that are either not strictly
required or things for which alternative implementations might be used.
What's left in zope.app will be core for the application server. One could
argue that the other required zope packages will be core too. <shrug>

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

Yes, and, as I said before, the meaning is a bit confused.

Right now, the most important questions are:

- What work needs to be done to release 1.0?

- How should the 1.0 release be described, so that people
   have clear expectations about what 1.0 is and isn't and
   can know what to expect for the future?

Some somewhat less important questions are:

- How should we arrange the sources to make them easier to understand and use>
   We are doing this again now because it may be our last chance.

- What should we include in the 1.0 distribution?

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

:)

I think that there is some consensus that both zope.app and zope.products
should be very flat.  Given this, I have to admit that the distinction
between zope.app and zope.products seems somehow to be less important.

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

This illustrates why I'm a little queasy about the add-on/core distinction
between zope.products and zope.app. There are a lot of ways we can
classify the software. Given that, it is perhaps counter productive
to carve the classifications into a package structure.  Perhaps there should
be a separate package catalog for zope paclages that superimposes
dynamic classification schems on the package structure.


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

Perhaps.

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

That's a benefit of Python packages in general. You don't need special
container packages to get that.

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

Again, I don't think you need a special container package to do that.
In fact, I think it makes it harder, which is why we've dropped
zopeproducts.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org