Hash: SHA1

Hanno Schlichting wrote:
> On Thu, Jan 21, 2010 at 3:45 PM, Chris McDonough <chr...@plope.com> wrote:
>> So it seems like a good idea to explicitly distinguish the set of packages 
>> that
>> BFG uses from "the ZTK" by giving the bicycle repair toolkit a name and 
>> saying
>> that the ZTK depends on that, if only to give another "target point" in a
>> diagram that includes frameworks that don't use the entire ZTK.  "ZCA" seems
>> good enough to me, although I don't really care what it's called.
> I think ZCA as in Zope Component Architecture defines quite well what
> BFG currently uses internally.
> It could be interesting to see if we can come up with better
> definitions of what micro-frameworks the ZTK is composed of. What kind
> of bags of technologies do we have that offer some consistent and
> useful feature?
> The ZCA seems to be one of those and the ZODB is another that has some
> identity to it.

The ZODB is explicitly not part of the ZTK, and is not subject to the
oversight of the ZTG SG.

> Possible other features could be:
> schemas

zope.configuration ends up pulling in zope.schema.  If you mean
something bigger (like the form libraries) OK.

> object publishing
> traversal / location

These two are intrinsically inseparable AFAIK.

> security / authentication

I do know of one user who reports using zope.security without the bigger
ZTK:  I would have said it was impossible elsewise.

> page templates / tal
> i18n

Mostly inseparable.

> catalog / indexes

Only one package AFAIK.

> web server (server, processlifetime)

> caching (ramcache, cache descriptors)
> mail handling
> browser components (pages, resources, menus)
> pluggable browser components (contentproviders, viewlets)
> form components (formlib)
> persistent components (container, copy/paste, lifecycleevent)

I' afriad I've forgotten everything I [ever knew about most of these

> persistent relationships (intid, keyreference)

zope.intid is a depencency of zope.catalog.  I don't think keyreferencs is.

> This list isn't all inclusive and it's not really clear what package
> belongs to which of these grous. The relationship between these and
> their dependencies isn't all too clear either. But I think if we want
> to create documentation or some identity and community around things,
> it makes more sense to do so on this kind of higher level than trying
> to do that on the level of our current packages.
> It's probably too early to do this yet and the community will focus
> first on getting BlueBream off to a great start and allow Grok to
> finish its move to the ZTK. This is just what Tres and Chris have been
> hinting at, when we talked about the term "framework" and what that
> really is :-)

I argued early on that there were actually multiple Zope Toolkits, so I
am very much in favor of identifying coherent subsets, particularly if
that makes it easier to identify the folks / communities of interest
attached to them.

- --
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to