Where is the position of BlueBream in Zope ecosystem ?
Hi All, I would like to get your opinion about this position statement, as it involve the wider Zope ecosystem. However, we tried to be diplomatic about other project's relationship with ZTK as we don't want to claim anything about others: http://wiki.zope.org/bluebream/BlueBreamName Regards, Baiju M
On Thu, Jan 21, 2010 at 3:56 AM, Baiju M <mbaiju@zeomega.com> wrote:
I would like to get your opinion about this position statement, as it involve the wider Zope ecosystem. However, we tried to be diplomatic about other project's relationship with ZTK as we don't want to claim anything about others:
Two things: - Repoze is a brand name like Zope but not a particular project. BFG is a web application framework. BFG was certainly never based on Zope 3. But even the claim that it is based on the ZTK is far fetched. It depends on zope.component, zope.configuration and their dependencies. That's similar to Twisted depending on zope.interface or TurboGears depending on zope.sqlalchemy and transaction. Presenting it as if the dependency of BFG onto the ZTK is similar in scope to Grok or Zope2 is misleading. - Plone isn't a web application framework but a specific application. Zope 2 is a web application framework. If you want to include Plone into the graph, you have to put it at a different level than the other things. And both the dependency on Zope 3 and the ZTK are mediated via the Zope 2 dependency. So a 2010 graph should read more like: Plone Zope2 Grok BlueBream BFG ZTK ZCA Where there's a direct line from BFG to ZCA bypassing the ZTK. In the 2008 version ZTK would be Zope 3 with BlueBream missing. Hanno
On Thu, Jan 21, 2010 at 9:05 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Jan 21, 2010 at 3:56 AM, Baiju M <mbaiju@zeomega.com> wrote:
I would like to get your opinion about this position statement, as it involve the wider Zope ecosystem. However, we tried to be diplomatic about other project's relationship with ZTK as we don't want to claim anything about others:
Two things:
- Repoze is a brand name like Zope but not a particular project. BFG is a web application framework. BFG was certainly never based on Zope 3. But even the claim that it is based on the ZTK is far fetched. It depends on zope.component, zope.configuration and their dependencies. That's similar to Twisted depending on zope.interface or TurboGears depending on zope.sqlalchemy and transaction. Presenting it as if the dependency of BFG onto the ZTK is similar in scope to Grok or Zope2 is misleading.
- Plone isn't a web application framework but a specific application. Zope 2 is a web application framework. If you want to include Plone into the graph, you have to put it at a different level than the other things. And both the dependency on Zope 3 and the ZTK are mediated via the Zope 2 dependency.
So a 2010 graph should read more like:
Plone Zope2 Grok BlueBream BFG ZTK ZCA
Where there's a direct line from BFG to ZCA bypassing the ZTK. In the 2008 version ZTK would be Zope 3 with BlueBream missing.
Thanks for the feedback. I have changed the Repoze to BFG. But the lines are just to indicate that there is some relation. We tried to be very careful when talking about the relation as we don't want to claim anything, at the same time, it doesn't contradict anything in reality: For example: "Over time, other web frameworks, such as Grok / BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server." In the case of Plone also, it's very true: "Other products, such as Plone also started to make use of the Zope 3 component architecture and the accompanied packages" Also we emphasized: "We cannot officially speak for other projects, so you can check their documentation to understand the relationship with ZTK" Sorry, we don't have any plan to show the exact relationship between projects. Regards, Baiju M
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Baiju M wrote:
On Thu, Jan 21, 2010 at 9:05 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Jan 21, 2010 at 3:56 AM, Baiju M <mbaiju@zeomega.com> wrote:
I would like to get your opinion about this position statement, as it involve the wider Zope ecosystem. However, we tried to be diplomatic about other project's relationship with ZTK as we don't want to claim anything about others:
Two things:
- Repoze is a brand name like Zope but not a particular project. BFG is a web application framework. BFG was certainly never based on Zope 3. But even the claim that it is based on the ZTK is far fetched. It depends on zope.component, zope.configuration and their dependencies. That's similar to Twisted depending on zope.interface or TurboGears depending on zope.sqlalchemy and transaction. Presenting it as if the dependency of BFG onto the ZTK is similar in scope to Grok or Zope2 is misleading.
- Plone isn't a web application framework but a specific application. Zope 2 is a web application framework. If you want to include Plone into the graph, you have to put it at a different level than the other things. And both the dependency on Zope 3 and the ZTK are mediated via the Zope 2 dependency.
So a 2010 graph should read more like:
Plone Zope2 Grok BlueBream BFG ZTK ZCA
Where there's a direct line from BFG to ZCA bypassing the ZTK. In the 2008 version ZTK would be Zope 3 with BlueBream missing.
Thanks for the feedback. I have changed the Repoze to BFG.
But the lines are just to indicate that there is some relation. We tried to be very careful when talking about the relation as we don't want to claim anything, at the same time, it doesn't contradict anything in reality:
For example:
"Over time, other web frameworks, such as Grok / BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server."
In the case of Plone also, it's very true:
"Other products, such as Plone also started to make use of the Zope 3 component architecture and the accompanied packages"
Also we emphasized:
"We cannot officially speak for other projects, so you can check their documentation to understand the relationship with ZTK"
Sorry, we don't have any plan to show the exact relationship between projects.
Channeling Chris here: BFG can't truly be said to be a Zope3-derived framework: it doesn't *require* application developers to use the ZCA, altho[ugh it happens to use the ZCA in its implementation (primarily as an optimization at this point). Its dependencies have never included more than a handful of Zope3 packages (zope.interface, zope.component, zope.configuration, and dependencies). Its notions of a view is radically different than a Zope3 view, for instance: in BFG, a view is nearly always just a function or other callable, and only rarely (primarily in migrated code) a class / factory taking context and request and returning a "view object." In 2010, *none* of the Zope3 technologies are "required knowlege" for a BFG developer: you can literally write a BFG app which imports *nothing* from the zope.* namespace at all (nor ZODB and related packages, etc.) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAktX4w0ACgkQ+gerLs4ltQ4/4ACgiPFOk3OuyTBhlBwaKtPx+xum Gm0AniQd3CzgBLXkzyHP5cWzwWW/JOtp =fsV5 -----END PGP SIGNATURE-----
On Thu, Jan 21, 2010 at 10:45 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Baiju M wrote:
On Thu, Jan 21, 2010 at 9:05 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Jan 21, 2010 at 3:56 AM, Baiju M <mbaiju@zeomega.com> wrote:
I would like to get your opinion about this position statement, as it involve the wider Zope ecosystem. However, we tried to be diplomatic about other project's relationship with ZTK as we don't want to claim anything about others:
http://wiki.zope.org/bluebream/BlueBreamName Two things:
- Repoze is a brand name like Zope but not a particular project. BFG is a web application framework. BFG was certainly never based on Zope 3. But even the claim that it is based on the ZTK is far fetched. It depends on zope.component, zope.configuration and their dependencies. That's similar to Twisted depending on zope.interface or TurboGears depending on zope.sqlalchemy and transaction. Presenting it as if the dependency of BFG onto the ZTK is similar in scope to Grok or Zope2 is misleading.
- Plone isn't a web application framework but a specific application. Zope 2 is a web application framework. If you want to include Plone into the graph, you have to put it at a different level than the other things. And both the dependency on Zope 3 and the ZTK are mediated via the Zope 2 dependency.
So a 2010 graph should read more like:
Plone Zope2 Grok BlueBream BFG ZTK ZCA
Where there's a direct line from BFG to ZCA bypassing the ZTK. In the 2008 version ZTK would be Zope 3 with BlueBream missing.
Thanks for the feedback. I have changed the Repoze to BFG.
But the lines are just to indicate that there is some relation. We tried to be very careful when talking about the relation as we don't want to claim anything, at the same time, it doesn't contradict anything in reality:
For example:
"Over time, other web frameworks, such as Grok / BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server."
In the case of Plone also, it's very true:
"Other products, such as Plone also started to make use of the Zope 3 component architecture and the accompanied packages"
Also we emphasized:
"We cannot officially speak for other projects, so you can check their documentation to understand the relationship with ZTK"
Sorry, we don't have any plan to show the exact relationship between projects.
Channeling Chris here:
BFG can't truly be said to be a Zope3-derived framework: it doesn't *require* application developers to use the ZCA, altho[ugh it happens to use the ZCA in its implementation (primarily as an optimization at this point). Its dependencies have never included more than a handful of Zope3 packages (zope.interface, zope.component, zope.configuration, and dependencies).
Its notions of a view is radically different than a Zope3 view, for instance: in BFG, a view is nearly always just a function or other callable, and only rarely (primarily in migrated code) a class / factory taking context and request and returning a "view object."
In 2010, *none* of the Zope3 technologies are "required knowlege" for a BFG developer: you can literally write a BFG app which imports *nothing* from the zope.* namespace at all (nor ZODB and related packages, etc.)
Please read the sentence once again: "BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server." We don't claim anything you said here. Each words are used very carefully. Regards, Baiju M
On Thu, Jan 21, 2010 at 10:53 AM, Baiju M <mbaiju@zeomega.com> wrote:
Please read the sentence once again:
"BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server."
We don't claim anything you said here. Each words are used very carefully.
Well, I added two more sentences at the beginning: The aim of this document is to show the position of BlueBream in the wider Zope ecosystem. Disclaimer: What is written about other projects should be taken with a pinch of salt, as we are not the maintainers of those projects. Regards, Baiju M
On Thu, Jan 21, 2010 at 11:03 AM, Baiju M <mbaiju@zeomega.com> wrote:
On Thu, Jan 21, 2010 at 10:53 AM, Baiju M <mbaiju@zeomega.com> wrote:
Please read the sentence once again:
"BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server."
We don't claim anything you said here. Each words are used very carefully.
Well, I added two more sentences at the beginning:
The aim of this document is to show the position of BlueBream in the wider Zope ecosystem. Disclaimer: What is written about other projects should be taken with a pinch of salt, as we are not the maintainers of those projects.
FTR, now Chris McDonough contributed new digram an updated text to include ZCA in picture. Thanks Chris ! Regards, Baiju M
Am Donnerstag 21 Januar 2010 07:48:30 schrieb Baiju M:
On Thu, Jan 21, 2010 at 11:03 AM, Baiju M <mbaiju@zeomega.com> wrote:
On Thu, Jan 21, 2010 at 10:53 AM, Baiju M <mbaiju@zeomega.com> wrote:
Please read the sentence once again:
"BFG evolved around Zope 3, which primarily utilize certain library packages from Zope 3 and don't make use of the Zope 3 application server."
We don't claim anything you said here. Each words are used very carefully.
Well, I added two more sentences at the beginning:
The aim of this document is to show the position of BlueBream in the wider Zope ecosystem. Disclaimer: What is written about other projects should be taken with a pinch of salt, as we are not the maintainers of those projects.
FTR, now Chris McDonough contributed new digram an updated text to include ZCA in picture. Thanks Chris !
Thanks from me, too! What could be added to the diagrams is the following: - A horizontal segmentation via a line, where above on the right we read "Web Frameworks" and below the line "Core Libraries" (or similar). In the 2008 diagram, this line would go right through Zope 3, as this covered both, whereas in the current diagram, the line would be above ZTK. The Grok/Zope2 arrows would then reach below this line to indicate that these projects rely on the core-library part of Zope 3. - Some legend like "Zope ecosystem in 2008/2010". I personally would very much like to see this graph, perhaps extended with an application layer with Plone (and maybe other products, e.g. Silva) on the zope.org page on a prominent place. The boxes in the graph could be links, so that people can directly navigate to the desired location. This would clear up things a lot, I think, especially for newcomers. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21.01.10 07:48, Baiju M wrote:
FTR, now Chris McDonough contributed new digram an updated text to include ZCA in picture. Thanks Chris !
In our marketing in Germany we put it just like this. We talk about component-based web-development with Zope and add BFG just in the way the graph indicates. juh DZUG e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktYK98ACgkQPUzUEFbILMTDOwCfT0KI/BCnhkkLZQxlEIEmaERF WcIAoJBBVnc8pF7oAZddJ3EG7YXRdc6l =K/Ku -----END PGP SIGNATURE-----
Am Donnerstag 21 Januar 2010 06:15:58 schrieb Tres Seaver:
Baiju M wrote:
On Thu, Jan 21, 2010 at 9:05 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Jan 21, 2010 at 3:56 AM, Baiju M <mbaiju@zeomega.com> wrote:
I would like to get your opinion about this position statement,
Channeling Chris here:
BFG can't truly be said to be a Zope3-derived framework: it doesn't *require* application developers to use the ZCA, altho[ugh it happens to use the ZCA in its implementation (primarily as an optimization at this point). Its dependencies have never included more than a handful of Zope3 packages (zope.interface, zope.component, zope.configuration, and dependencies).
Its notions of a view is radically different than a Zope3 view, for instance: in BFG, a view is nearly always just a function or other callable, and only rarely (primarily in migrated code) a class / factory taking context and request and returning a "view object."
In 2010, *none* of the Zope3 technologies are "required knowlege" for a BFG developer: you can literally write a BFG app which imports *nothing* from the zope.* namespace at all (nor ZODB and related packages, etc.)
Thanks for clearing this up. What I don't understand is: Is ZCA now part of the ZTK or not? I had the impression that ZCA is merely a set of libraries inside the ZTK? Who maintains ZCA? Is this the ZTK steering group or somebody else? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Thu, Jan 21, 2010 at 08:29, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Thanks for clearing this up. What I don't understand is: Is ZCA now part of the ZTK or not? I had the impression that ZCA is merely a set of libraries inside the ZTK?
"Merely"? :) The ZCA is a set of libraries that together make a component architecture for Python, yes. ZTK uses/includes these libraries. Is that "inside" are "below" or "above"? Does it matter? :-)
Who maintains ZCA? Is this the ZTK steering group or somebody else?
People who have checkin access on the Zope svn. The ZCA is pretty stable, so there are not amazing amounts of maintenance going on anyway. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Am Donnerstag 21 Januar 2010 09:29:46 schrieb Lennart Regebro:
On Thu, Jan 21, 2010 at 08:29, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Thanks for clearing this up. What I don't understand is: Is ZCA now part of the ZTK or not? I had the impression that ZCA is merely a set of libraries inside the ZTK?
"Merely"? :) The ZCA is a set of libraries that together make a component architecture for Python, yes. ZTK uses/includes these libraries. Is that "inside" are "below" or "above"? Does it matter?
I think such things indeed matter to some degree: It's interesting that even people who are not that new (like Baiju or me) can't easily draw a picture of the Zope ecosystem, for instance neither of us knew that BFG sits on ZCA and not on ZTK, whereas I would not have distinguished between ZCA and ZTK in the first place. So - if even we have problems understanding, how would things look like for complete newbies? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Thu, Jan 21, 2010 at 10:13, Hermann Himmelbauer <dusty@qwer.tk> wrote:
whereas I would not have distinguished between ZCA and ZTK in the first place.
I guess that's because the discussion has been around the ZTK. The ZCA has been around uncontroversially for years, so there's no news to discuss. :)
So - if even we have problems understanding, how would things look like for complete newbies?
I don't think we have problems understanding. It was just a question of not knowing the requirements of BFG. Now we know. Done. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 2010-01-21, Hermann Himmelbauer <dusty@qwer.tk> wrote:
I think such things indeed matter to some degree: It's interesting that even people who are not that new (like Baiju or me) can't easily draw a picture of the Zope ecosystem, for instance neither of us knew that BFG sits on ZCA and not on ZTK, whereas I would not have distinguished between ZCA and ZTK in the first place.
So - if even we have problems understanding, how would things look like for complete newbies?
+1 FWIW I think of the ZCA as: The "abstract concepts that define modern Zope programming" e.g. component, adapter, interface, view, utility, etc. which is most often compared and contrasted with "old style" Zope 2 programming, e.g. acquisition, traversal, etc. As such, I make a pretty big distinction between the ZCA and the rest, e.g. Zope 2, the ZTK, BlueBream, Grok, BFG, Plone et al. The former is a concept, the latter are implementations of that concept, to varying degrees. I don't know or particularly care what packages make up the particular products/frameworks/whatever. (In fact, I find the whole ZTK concept a bit confusing. If the ZTK is just a collection of packages why argue over which packages? Why not declare every damn "Zope-ish" package part of the ZTK? That would include Chris's BFG, which implements CA concepts. So why not? Who cares? :-) We certainly have not reached the goal of helping newcomers understand the Zope ecosystem in any other way to date, IMO.) With that in mind, I can view the ecosystem very much like: http://wiki.zope.org/bluebream/BlueBreamName. But I might draw it like this: # Zope Ecosystem # ============== # # .----------------------------------------------------------------------. # |ZCA (abstract concepts) | # | .-----------------------------------------------------. | # | |ZTK (a bunch of Zope-ish packages that may or may not | | # | | be useful to you) | | # | | --------- --------- ------- ------- | | # | | | | | | | | | | | | # | | |BlueBream| | Grok | | BFG | | Zope2 | | | # | | | | | | | | | | | | # | | --------- --------- ------- ------- | | # | | | | # | | -------------- | | # | | | repoze.zope2*| | | # | | -------------- | | # | `-----------------------------------------------------` | # | | # `----------------------------------------------------------------------` So I guess the point is, you can draw BFG with a line pointing directly to the ZCA and explicitly avoiding the ZTK, but I'm not buying it, personally ;-) Why? Because I consider BFG and whatever packages it consists of to be part of the general set of tools I may use as a Python/Zope loving web developer. And what's a good name for a set of tools that I may use to build something? Wait for it… a toolkit! Alex P.S. *Merge me back to Zope 2 Hanno, please!
Best Regards, Hermann
-- Alex Clark · http://aclark.net Practical Plone 3 · http://tinyurl.com/practical-plone
On Fri, Jan 22, 2010 at 04:55, Alex Clark <aclark@aclark.net> wrote:
We certainly have not reached the goal of helping newcomers understand the Zope ecosystem in any other way to date, IMO.)
If this is so, then I'm surprised. It seems perfectly clear to me. 1. In the beginning there is Python, the language. 2. Then you get ZCA a component architecture for Python. It has nothing to do with Web whatsoever. 3. Then we have ZTK. A toolkit for building web frameworks. 4. On top of that we have Zope 2, BlueBream and Grok. 5. There is also BFG, which doesn't include/build on the ZTK (as the others do). It's pretty clear to me. Notice the almost complete lack of naming confusion, and the plethora of marketable names and TLA's. The paper pushers like these kinds of graphs (although I think we need something prettier, I might try do do something this weekend, but I'm no designer...) And when it comes to separating the frameworks it obviously becomes more complex. So we need to explain this, what the different framworks are good at in a clear way. I see it like this, but I could be wrong: * Zope 2 is the granddaddy of the frameworks. It's not really built on top of ZTK, but includes it. You basically only use Zope 2 if you are using some sort of software that builds on it, like Plone, Silva, or something custom. To build on my earlier car analogy: Zope 2 is an old pickup truck. You can get it to do anything. You can drop it from the top of a building and it will run. When it breaks you whack it with a hammer until it's not broken anymore. But it's diesel engine kinda stinks. * BlueBream used to be called Zope 3 and is a component based enterprise kick-ass do everything framework. Everything is configurable and it doesn't just include batteries, but a whole power plant. Which admittedly can be tricky to run. BlueBream is a train. Fast, big and pulls heavy loads, and good for the environment. If that's what you need, you know it. * Grok is an easier to use (and at least in the future also smaller/lighter) framework than BlueBream, while retaining the flexibility. Instead of having to configure everything, you have sensible defaults. Less typing, and it doesn't feel like J2EE. Inspired by frameworks like Django and Turbogears, you get the nice Python framework feeling with the power of ZTK behind you. Grok is a an hybrid minibus. Easy to drive, infinitely reconfigurable just by switching the seats around. * BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster. BFG is a frame with four wheels and an big engine. The rest is up to you. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Am Freitag 22 Januar 2010 14:46:16 schrieb Lennart Regebro:
On Fri, Jan 22, 2010 at 04:55, Alex Clark <aclark@aclark.net> wrote:
We certainly have not reached the goal of helping newcomers understand the Zope ecosystem in any other way to date, IMO.)
If this is so, then I'm surprised. It seems perfectly clear to me.
1. In the beginning there is Python, the language.
2. Then you get ZCA a component architecture for Python. It has nothing to do with Web whatsoever.
3. Then we have ZTK. A toolkit for building web frameworks.
4. On top of that we have Zope 2, BlueBream and Grok.
5. There is also BFG, which doesn't include/build on the ZTK (as the others do).
It's pretty clear to me. Notice the almost complete lack of naming confusion, and the plethora of marketable names and TLA's. The paper pushers like these kinds of graphs (although I think we need something prettier, I might try do do something this weekend, but I'm no designer...)
No problem that you are no designer, if the concept is clearly communicated, there will be people around who can prettify it.
And when it comes to separating the frameworks it obviously becomes more complex. So we need to explain this, what the different framworks are good at in a clear way. I see it like this, but I could be wrong:
The above list (and http://wiki.zope.org/bluebream/relationship-after.png, which resembles the list) pretty much explains and structures things. Personally, I think that Plone (and maybe other applications, e.g. Silva?) are missing in the big picture (not necessary for explaining BlueBream, though). The problem I see is where to go from this graph/list. I personally would expect to be able to advance from there to project home pages. This is true for grok/zope2/bluebream (in .zope.org), and also for BFG (bfg.repoze.org). What I can't find is some entry page for ZTK (at least I find http://docs.zope.org/zopetoolkit). Nice would be something like "ztk.zope.org" which could be similar to zope2.zope.org. When it gets to ZCA, I can't find anything, except for Baiju's book and maybe somewhere some document about the Zope Component Architecture. If we introduce the word ZCA, I would recommend to put up a simple page on e.g. "zca.zope.org", where people can learn what this is, links to a documentation and maybe has some download/install information and some tutorial. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Fri, Jan 22, 2010 at 7:58 PM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
When it gets to ZCA, I can't find anything, except for Baiju's book and maybe somewhere some document about the Zope Component Architecture. If we introduce the word ZCA, I would recommend to put up a simple page on e.g. "zca.zope.org", where people can learn what this is, links to a documentation and maybe has some download/install information and some tutorial.
If somebody is going to work on this, I have collected all the links I found about ZCA here: http://wiki.zope.org/zope3/ComponentArchitecture Regards, Baiju M
On 2010-01-22, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Am Freitag 22 Januar 2010 14:46:16 schrieb Lennart Regebro:
On Fri, Jan 22, 2010 at 04:55, Alex Clark <aclark@aclark.net> wrote:
We certainly have not reached the goal of helping newcomers understand the Zope ecosystem in any other way to date, IMO.)
If this is so, then I'm surprised. It seems perfectly clear to me.
1. In the beginning there is Python, the language.
2. Then you get ZCA a component architecture for Python. It has nothing to do with Web whatsoever.
3. Then we have ZTK. A toolkit for building web frameworks.
4. On top of that we have Zope 2, BlueBream and Grok.
5. There is also BFG, which doesn't include/build on the ZTK (as the others do).
It's pretty clear to me. Notice the almost complete lack of naming confusion, and the plethora of marketable names and TLA's. The paper pushers like these kinds of graphs (although I think we need something prettier, I might try do do something this weekend, but I'm no designer...)
No problem that you are no designer, if the concept is clearly communicated, there will be people around who can prettify it.
And when it comes to separating the frameworks it obviously becomes more complex. So we need to explain this, what the different framworks are good at in a clear way. I see it like this, but I could be wrong:
The above list (and http://wiki.zope.org/bluebream/relationship-after.png, which resembles the list) pretty much explains and structures things. Personally, I think that Plone (and maybe other applications, e.g. Silva?) are missing in the big picture (not necessary for explaining BlueBream, though).
+1
The problem I see is where to go from this graph/list. I personally would expect to be able to advance from there to project home pages. This is true for grok/zope2/bluebream (in .zope.org), and also for BFG (bfg.repoze.org).
What I can't find is some entry page for ZTK (at least I find http://docs.zope.org/zopetoolkit). Nice would be something like "ztk.zope.org" which could be similar to zope2.zope.org.
+1
When it gets to ZCA, I can't find anything, except for Baiju's book and maybe somewhere some document about the Zope Component Architecture. If we introduce the word ZCA, I would recommend to put up a simple page on e.g. "zca.zope.org", where people can learn what this is, links to a documentation and maybe has some download/install information and some tutorial.
Right, I see http://pypi.python.org/pypi/zope.component/3.9.1 wrt to ZCA.
Best Regards, Hermann
-- Alex Clark · http://aclark.net Practical Plone 3 · http://tinyurl.com/practical-plone
On Fri, Jan 22, 2010 at 15:28, Hermann Himmelbauer <dusty@qwer.tk> wrote:
What I can't find is some entry page for ZTK (at least I find http://docs.zope.org/zopetoolkit).
Well isn't that enough? It's nothing you can download and test, it's a collection of libraries of limited interest outside those who use Zope webframeworks.
When it gets to ZCA, I can't find anything, except for Baiju's book and maybe somewhere some document about the Zope Component Architecture.
Yeah, the component architecture maybe could use some more advertising. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 22.01.10 19:42, Lennart Regebro wrote:
Yeah, the component architecture maybe could use some more advertising.
FullACK I think the ZCA is our USP. As I said before, we will launch a new zope.de website in Germany soon and produce a imagebroschure about Zope which will both emphasize this point. I really enjoy the discussion so far. Many valuable hints and good statements. juh DZUG e.V.
On 2010-01-22, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Jan 22, 2010 at 04:55, Alex Clark <aclark@aclark.net> wrote:
We certainly have not reached the goal of helping newcomers understand the Zope ecosystem in any other way to date, IMO.)
If this is so, then I'm surprised. It seems perfectly clear to me.
Ah! This is tremendously helpful, thanks. Just a few questions/comments.
1. In the beginning there is Python, the language.
2. Then you get ZCA a component architecture for Python. It has nothing to do with Web whatsoever.
E.g. zope.component and one or two others?
3. Then we have ZTK. A toolkit for building web frameworks.
This is where you lose me. What's an example of a ZTK package? I can't think of one off the top of my head… ah ok, I just found this: - http://docs.zope.org/zopetoolkit/releases/packages-trunk.html So ZTK is ZCA plus the bits that make it suitable for building web frameworks. And is it fair to say I can just build any web app with the ZTK? I don't need any of the frameworks that are already built, I'm free to reinvent the wheel if I choose too.
4. On top of that we have Zope 2, BlueBream and Grok.
I.e. The Frameworks™
5. There is also BFG, which doesn't include/build on the ZTK (as the others do).
Right, it's "loosely coupled" with the ZCA, but you can throw that out too, if you like?
It's pretty clear to me. Notice the almost complete lack of naming confusion, and the plethora of marketable names and TLA's. The paper pushers like these kinds of graphs (although I think we need something prettier, I might try do do something this weekend, but I'm no designer...)
And when it comes to separating the frameworks it obviously becomes more complex. So we need to explain this, what the different framworks are good at in a clear way. I see it like this, but I could be wrong:
* Zope 2 is the granddaddy of the frameworks. It's not really built on top of ZTK, but includes it. You basically only use Zope 2 if you are using some sort of software that builds on it, like Plone, Silva, or something custom.
To build on my earlier car analogy: Zope 2 is an old pickup truck. You can get it to do anything. You can drop it from the top of a building and it will run. When it breaks you whack it with a hammer until it's not broken anymore. But it's diesel engine kinda stinks.
* BlueBream used to be called Zope 3 and is a component based enterprise kick-ass do everything framework. Everything is configurable and it doesn't just include batteries, but a whole power plant. Which admittedly can be tricky to run.
BlueBream is a train. Fast, big and pulls heavy loads, and good for the environment. If that's what you need, you know it.
* Grok is an easier to use (and at least in the future also smaller/lighter) framework than BlueBream, while retaining the flexibility. Instead of having to configure everything, you have sensible defaults. Less typing, and it doesn't feel like J2EE. Inspired by frameworks like Django and Turbogears, you get the nice Python framework feeling with the power of ZTK behind you.
Grok is a an hybrid minibus. Easy to drive, infinitely reconfigurable just by switching the seats around.
* BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster.
BFG is a frame with four wheels and an big engine. The rest is up to you.
Right, and the apps built with those frameworks, e.g. Plone, Cyn.in, Zenoss, etc. Would be very helpful to include these in a discussion about this, IMO.
-- Alex Clark · http://aclark.net Practical Plone 3 · http://tinyurl.com/practical-plone
On Fri, Jan 22, 2010 at 15:38, Alex Clark <aclark@aclark.net> wrote:
2. Then you get ZCA a component architecture for Python. It has nothing to do with Web whatsoever.
E.g. zope.component and one or two others?
Yup.
3. Then we have ZTK. A toolkit for building web frameworks.
This is where you lose me. What's an example of a ZTK package? I can't think of one off the top of my head… ah ok, I just found this:
- http://docs.zope.org/zopetoolkit/releases/packages-trunk.html
So ZTK is ZCA plus the bits that make it suitable for building web frameworks. And is it fair to say I can just build any web app with the ZTK? I don't need any of the frameworks that are already built, I'm free to reinvent the wheel if I choose too.
Sure. Or for example, use it together with Pylons, or Bobo, or for that matter BFG.
4. On top of that we have Zope 2, BlueBream and Grok.
I.e. The Frameworks™
Yup.
5. There is also BFG, which doesn't include/build on the ZTK (as the others do).
Right, it's "loosely coupled" with the ZCA, but you can throw that out too, if you like?
Chris has to answer that. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
5. There is also BFG, which doesn't include/build on the ZTK (as the others do). Right, it's "loosely coupled" with the ZCA, but you can throw that out too, if you like?
Chris has to answer that.
BFG uses some Zope software, like, say, Pylons uses software made by Ian Bicking. This is about the best way to describe the relationship. The fact that BFG is built on top of the ZCA is an implementation detail. As a consumer of BFG (as a "programmer of a BFG application"), you aren't going to throw out the ZCA, because a) there'd be no reason to do so, it's an implementation detail that is invisible to you and b) BFG would stop working. In the future, BFG may or may not depend on the set of Zope packages on which it currently depends. It may begin to depend on more Zope packages, or fewer, or disuse all of them entirely. But whatever decisions are made wrt its Zope dependencies, BFG will be largely backwards compatible with itself between releases. - C
Does this mailinglist accept attachements? Let's test. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Cool picture, but I might put ZCA at its own level (maybe by moving Zope Toolkit to the framework level, or giving it its own level). - C Lennart Regebro wrote:
Does this mailinglist accept attachements?
Let's test.
------------------------------------------------------------------------
On Fri, Jan 22, 2010 at 22:09, Chris McDonough <chrism@plope.com> wrote:
Cool picture, but I might put ZCA at its own level (maybe by moving Zope Toolkit to the framework level, or giving it its own level).
It's possible that the component level is pointless. I mostly wanted the framework level and the application level, and I stuck the component level in there too, while I was at it. :) I also don't know of any applications running on the other frameworks, which is why it's so empty there. I guess I should upload the svg somewhere. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Fri, Jan 22, 2010 at 10:37 PM, Lennart Regebro <regebro@gmail.com> wrote:
I also don't know of any applications running on the other frameworks, which is why it's so empty there.
SchoolTool and Launchpad have been mentioned as Zope3 applications in the past. Karl would be an example for BFG. Not sure if there's a canonical example for Grok. Hanno
On Fri, Jan 22, 2010 at 22:44, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Fri, Jan 22, 2010 at 10:37 PM, Lennart Regebro <regebro@gmail.com> wrote:
I also don't know of any applications running on the other frameworks, which is why it's so empty there.
SchoolTool and Launchpad have been mentioned as Zope3 applications in the past. Karl would be an example for BFG. Not sure if there's a canonical example for Grok.
Ah, yes, Schooltool and KARL, of course, I forgot about them. Is Launchpad available as an application you can install and run? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Jan 22, 2010, at 4:51 PM, Lennart Regebro wrote:
On Fri, Jan 22, 2010 at 22:44, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Fri, Jan 22, 2010 at 10:37 PM, Lennart Regebro <regebro@gmail.com> wrote:
I also don't know of any applications running on the other frameworks, which is why it's so empty there.
SchoolTool and Launchpad have been mentioned as Zope3 applications in the past. Karl would be an example for BFG. Not sure if there's a canonical example for Grok.
Ah, yes, Schooltool and KARL, of course, I forgot about them. Is Launchpad available as an application you can install and run?
Nominally, yes. If you are willing to let it have its way with your system. Gary
On Fri, Jan 22, 2010 at 10:51 PM, Lennart Regebro <regebro@gmail.com> wrote:
Is Launchpad available as an application you can install and run?
For some definition of that, yes: https://dev.launchpad.net/ Hanno
Am Freitag 22 Januar 2010 22:00:57 schrieb Lennart Regebro:
Does this mailinglist accept attachements?
Let's test.
That is cool and understandable! Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On 1/22/10 14:46 , Lennart Regebro wrote:
* BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster.
BFG uses the ZCA for some implementation details, I'm not sure if that is the same as 'builds on the ZCA'. I don't think you can use the ZTK with BFG - the vast majority of ZTK packages are too tied to concepts that do not apply to BFG. Wichert.
On Fri, Jan 22, 2010 at 4:11 PM, Wichert Akkerman <wichert@wiggy.net> wrote:
BFG uses the ZCA for some implementation details, I'm not sure if that is the same as 'builds on the ZCA'. I don't think you can use the ZTK with BFG - the vast majority of ZTK packages are too tied to concepts that do not apply to BFG.
In the same way Zope2 doesn't really built on the ZTK. It's integrated in some parts of it while a lot is still agnostic to it. Parts of the ZTK like the entire security machinery don't apply. But there's certainly some relationship that qualifies as "uses" between these entities. I'd say the same is true for BFG. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
On 1/22/10 14:46 , Lennart Regebro wrote:
* BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster.
BFG uses the ZCA for some implementation details, I'm not sure if that is the same as 'builds on the ZCA'. I don't think you can use the ZTK with BFG - the vast majority of ZTK packages are too tied to concepts that do not apply to BFG.
BFG applications won't likely use the ZTK as a whole, but many of the deployed ones do use some ZTK packages beyond the bare ZCA parts. e.g. the catalog code, SMTP integration, etc. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAktZ40oACgkQ+gerLs4ltQ7KswCgtK57QR3ARWLfriVzLD1+uiEA l2QAnj8OFhuy8yvRqWQ7cETVt7G659kM =A9V/ -----END PGP SIGNATURE-----
On 2010-1-22 18:41, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wichert Akkerman wrote:
On 1/22/10 14:46 , Lennart Regebro wrote:
* BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster.
BFG uses the ZCA for some implementation details, I'm not sure if that is the same as 'builds on the ZCA'. I don't think you can use the ZTK with BFG - the vast majority of ZTK packages are too tied to concepts that do not apply to BFG.
BFG applications won't likely use the ZTK as a whole, but many of the deployed ones do use some ZTK packages beyond the bare ZCA parts. e.g. the catalog code, SMTP integration, etc.
I thought repoze forked exactly those parts (repoze.catalog and repoze.sendmail) to get rid of all the ZTK-assumptions? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
On 2010-1-22 18:41, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wichert Akkerman wrote:
On 1/22/10 14:46 , Lennart Regebro wrote:
* BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster. BFG uses the ZCA for some implementation details, I'm not sure if that is the same as 'builds on the ZCA'. I don't think you can use the ZTK with BFG - the vast majority of ZTK packages are too tied to concepts that do not apply to BFG. BFG applications won't likely use the ZTK as a whole, but many of the deployed ones do use some ZTK packages beyond the bare ZCA parts. e.g. the catalog code, SMTP integration, etc.
I thought repoze forked exactly those parts (repoze.catalog and repoze.sendmail) to get rid of all the ZTK-assumptions?
We had to fork the catalog (as repoze.catalog), and we've kept it forked mostly due to the assumptions made by zope.app.catalog (now zope.catalog) that it was dealing with a structure which contained a Zope 3 "site", that it was set up to listen for events sent by containerish Zope3 objects, and that it knew how to resolve document identifiers to objects. None of these things are true when you try to use the software outside a Zope instance. repoze.sendmail was a little more gratuitous (we needed to change it fast, without any arguments). Its changes have now actually been merged upstream to zope.sendmail by Fabio. - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
On 2010-1-22 18:41, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wichert Akkerman wrote:
On 1/22/10 14:46 , Lennart Regebro wrote:
* BFG is a minimalistic web framework built on Zope ideas and experiences, but as a part of it's minimalistic nature does not include *anything* of the ZTK, it just builds on the ZCA. But you can use the ZTK, if you want to, you are just not required to do so. It's for the purist, for the guy who wants to build his own streamlined speedmonster. BFG uses the ZCA for some implementation details, I'm not sure if that is the same as 'builds on the ZCA'. I don't think you can use the ZTK with BFG - the vast majority of ZTK packages are too tied to concepts that do not apply to BFG. BFG applications won't likely use the ZTK as a whole, but many of the deployed ones do use some ZTK packages beyond the bare ZCA parts. e.g. the catalog code, SMTP integration, etc.
I thought repoze forked exactly those parts (repoze.catalog and repoze.sendmail) to get rid of all the ZTK-assumptions?
I wrote a bit too casually: repoze.catalog still uses zope.index, but does not depend on zope.catalog. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAktaE7kACgkQ+gerLs4ltQ7DRQCfZ8RKWWtYWP05UZsOR54NCGWC wwAAni/g/6dTi1Vql5h8lAgU/ZkcLz9K =hwM0 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hermann Himmelbauer wrote:
Thanks for clearing this up. What I don't understand is: Is ZCA now part of the ZTK or not? I had the impression that ZCA is merely a set of libraries inside the ZTK? Who maintains ZCA? Is this the ZTK steering group or somebody else?
I used "ZCA" to refer to the subset of the ZTK used to do the actual component architecture (zope.interface, zope.component, zope.configuration, and dependencies). There is no separately-managed entity called the "ZCA": I have also jokingly referred to it in the past as the "bicycle seat toolkit." Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAktYUykACgkQ+gerLs4ltQ5bqQCgoU/fh5G43yKBSyeGqDBRzguI YRkAn04r7eOd3Bt3eLFo+uBlfrMROZ1M =Ln+v -----END PGP SIGNATURE-----
Everything Tres said I agree with. I think it's useful for descriptions of Zope-related frameworks to include BFG and other frameworks that use a small number of Zope technologies. But I think some distinction needs to be made between "the ZTK" and "some Zope packages". In particular, I'm uncomfortable with descriptions of BFG that say it "depends on the ZTK" because the current formal definition of the ZTK is what's in its buildout include file, or at least its defined by the packages listed at http://docs.zope.org/zopetoolkit/releases/packages-trunk.html. By this definition, BFG isn't (and will never be) a "ZTK consumer", because it doesn't use 95% of those packages; however it is very much a bicycle repair kit consumer. 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. - C Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hermann Himmelbauer wrote:
Thanks for clearing this up. What I don't understand is: Is ZCA now part of the ZTK or not? I had the impression that ZCA is merely a set of libraries inside the ZTK? Who maintains ZCA? Is this the ZTK steering group or somebody else?
I used "ZCA" to refer to the subset of the ZTK used to do the actual component architecture (zope.interface, zope.component, zope.configuration, and dependencies). There is no separately-managed entity called the "ZCA": I have also jokingly referred to it in the past as the "bicycle seat toolkit."
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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
iEYEARECAAYFAktYUykACgkQ+gerLs4ltQ5bqQCgoU/fh5G43yKBSyeGqDBRzguI YRkAn04r7eOd3Bt3eLFo+uBlfrMROZ1M =Ln+v -----END PGP SIGNATURE-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
On Thu, Jan 21, 2010 at 3:45 PM, Chris McDonough <chrism@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. Possible other features could be: schemas object publishing traversal / location security / authentication page templates / tal i18n catalog / indexes 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) persistent relationships (intid, keyreference) 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 :-) Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Thu, Jan 21, 2010 at 3:45 PM, Chris McDonough <chrism@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 packages.
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. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAktY9HoACgkQ+gerLs4ltQ4T0gCgroEtgR9kuFzEx4nDCq6ESHa5 rTEAn1Tyj4mZIJIRkCFW8jKIJp+pWTzx =O7i0 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris McDonough wrote:
Everything Tres said I agree with.
I think it's useful for descriptions of Zope-related frameworks to include BFG and other frameworks that use a small number of Zope technologies. But I think some distinction needs to be made between "the ZTK" and "some Zope packages".
In particular, I'm uncomfortable with descriptions of BFG that say it "depends on the ZTK" because the current formal definition of the ZTK is what's in its buildout include file, or at least its defined by the packages listed at http://docs.zope.org/zopetoolkit/releases/packages-trunk.html.
By this definition, BFG isn't (and will never be) a "ZTK consumer", because it doesn't use 95% of those packages; however it is very much a bicycle repair kit consumer.
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.
The ZTK steering group does give a tiny bit of formal recognition to the "ZCA" / "bicycle seat toolkit" subset, in that those packages are supposed to try harder to keep compatibility with Python 2.4 than the larger set which is the ZTK proper. This de facto recognition is precisely because the ZCA pacakges are already in wide use outside the "Zope ecosphere", IIRC. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAktY8x4ACgkQ+gerLs4ltQ4WXwCgnEcHV/TqHtCa+6iQrm1xRa4k 7vwAn1DjFhWDAyPrtUzSDPKoEA4BigV6 =QD4Q -----END PGP SIGNATURE-----
On Thu, Jan 21, 2010 at 14:14, Tres Seaver <tseaver@palladion.com> wrote:
There is no separately-managed entity called the "ZCA"
Right. And it has never been strictly defined what's included in it. Personally I'd define it as zope.component and requirements, which apparently is zope.event and zope.interface, today. (I'm pretty sure it included zope.exception just a month or two ago?) Those three packages is all you need to start writing components, so, it's the component architecture. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
participants (10)
-
Alex Clark -
Baiju M -
Chris McDonough -
Gary Poster -
Hanno Schlichting -
Hermann Himmelbauer -
Jan Ulrich Hasecke -
Lennart Regebro -
Tres Seaver -
Wichert Akkerman