-----BEGIN PGP SIGNED MESSAGE-----
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
>> BFG uses from "the ZTK" by giving the bicycle repair toolkit a name and
>> 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:
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
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -