On Feb 24, 2005, at 7:21 AM, Antonio Gallardo wrote:
On Jue, 24 de Febrero de 2005, 5:53, Joerg Heinicke dijo:Stefano Mazzocchi <stefano <at> apache.org> writes:
Just like other people, I think distinguishing "core blocks" is a good
thing to show people where to look at while still keeping the coresmall.
I'm sorry, but I think the "core block" idea is plain wrong and smells
of over componentization.
I'm not sure about this. See far below.
If we *all* agree that something is required (which is what a 'core block' appears to be) then we should not allow people to live without it.
I think you're on to something here. But not much is essential to "every deployment".
And the point is that CForms is just not required. As Peter pointed out
many
people can live without it (we too at the moment).
What is required by every possible use of Cocoon?
We need to have an answer to what "cocoon is" and what basic features it
provides. Having everything optional is diluting our brand and making
documentation and marketing harder.
Yes, but distributing a build with the basic features is different from allowing users to remove the features they do not use. The key is to make it easy to remove features or components.
I can't see why we should abandon the option to remove easily stuff
somebody
does not need. The idea of documenting and delivering it with the core,
but
storing it in an extra block, so anybody can remove it when needed, is the
best
I can imagine. We still can brand Cocoon as web application framework.
First, I am in the same position as you. I will like a highly configurable
cocoon. The presented analogy to the linux kernel was very good.
What I can do only with the linux kernel?
Answer: Nothing. The kernel alone is not useful to work. We need another
packages (read cocoon blocks) to get a system useful for a user. Every
Linux distribution contains hundreds of packages and the set of packages
is what makes the OS interesting.
Exactly.
In the same way, I will like to have the cocoon core with only the real
basic machinery. Then the user will be able to choose the other blocks he
needs to make the work done.
I think we have to look at this from multiple angles. We need to consider dependency and we need to consider brand and distribution. From a dependency point of view we don't want anything that is stable depending on anything less stable. To this end core should be extremely stable. It should be as abstract as possible. That is it should include only those interfaces, abstract classes and classes that are essential for any Cocoon deployment. This would exclude all concrete implementations of generators, transformers, serializers, actions and flow. Core by itself is not very functional, but I think from a design and conceptual view its important to make core the framework upon which Cocoon applications are built.
From a brand point of view it makes no sense to offer a framework with no implementation. So of course the basic distribution needs to include the basic generators, transformers, serializers, flows, CForms and anything else the community decides is part of the essential Cocoon distribution. This could be referred to as the core block. What gets included in here is open to debate. Because some desire that Cocoon be infinitely configurable, it might make sense that the core block be composed of other blocks, say a basic generator/transformer/serializer block, javaflow block, javascript flow block, CForms block (I see its almost stable :-)), etc. Anything in the core block should be extremely stable since these are the components users and developers are most likely to depend on to build their application.
In short, lets shift the terminology a bit and consider core only the basic framework and consider the essential elements of Cocoon the core block. I think this makes sense now and especially when real blocks finally arrive.
Glen Ezkovich HardBop Consulting glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
