Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
We can also release with non OSGi blocks. The blocks are ongoing work,
the most important thing that lacks is "two level configuration". As
discussed before the component configuration is part of the block and
constant, so they need to be parametrized in some way for making them
user configurable. We have not had much discussion about how to do
this yet.
My understanding is that a user can parameterize a block at deployment
(which is supported by the block deployer) if he wants. Otherwise the
default values are taken.
Yes, but that says nothing about the details about parametrization of
components (which isn't implemented yet), does it?
Also the APIs and concepts for blocks need to actually be used for
some real life examples before we can be convinced that we got it right.
Of course. I'm working on getting trunk as far as making it very simple
to use it for custom projects. Then I will start to rework at least one
of my projects to use blocks and learn more about their real life usage.
We should make it easy that at least we developers (and some brave
users) can start to experiment.
Hope to be able to use it in my projects as well.
Gradual steps, release often is good.
Agree, but as it will be the first release from trunk the threshold is
higher.
IMO we should consolidate the current status and make trunk useable for
projects again which should result in agreeing on our external contracts.
Yes
Making life harder for future
exciting developments by releasing too early isn't good.
Exactly, one point i that trunk contains nice mechanisms for
parameterizing components and sitemaps at a global level and also for
having foreign component managers within sitemaps. While very usefull
for the current development style in Cocoon they are not very relevant
for blocks. For blocks we should avoid global configurations as it is
in the way for splitting Cocoon in small reusable parts. And also
component configurations in sitemaps is rather unnecessary when we
have component configurations on the block level.
So what should we do about introducing things that we know that we
will want to remove in a later release?
As long as we have milestone releases, I have no problem with sitemap
classloaders and sitemap application containers. If both features become
block functionality, people have to migrate. (IIRC also Eclipse had some
incompatible changes in their 3.0 milestone series.)
I have not that much problem with the sitemap stuff, it shouldn't be
that hard to migrate them. I'm more concerned about the Core and
Settings objects, that is part of the trunk contract and that doesn't
fit well into a splited up non-monolithic architecture.
If this is the case, then it would seem timely to improve these
interfaces now, as 2.2 given the greater flexibility could become
_the_
future Cocoon, and we may miss the boat if we don't make this
change now.
Yes, I feel some urgency. With enough focus and dedication on
refactoring Cocoon and finish the blocks Cocoon can be the Rich Server
Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And
regain its momentum. Focusing on 2.2 seem more like losing valuable
time
for me.
Well, define 2.2 :-)
I presume you mean releasing a Maven based Cocoon without a ready blocks
system would loose valuable momentum.
Yes.
Do you have a roadmap on what's open?
* Component handling - design issues
* Logging - I put it in the BlocksManager but didn't give it much
thought, here is a new chance for all logging enthusiasts to discuss ;)
* Multi part MIME handling - not part of the blocks architecture to
simplify things, would make most sense to put in a ServletFilter IMO
* Error handling - there is sophisticated creation of error messages in
the CocoonServlet, where is the right place for it in the blocks
architecture?
* JARed blocks - the BlocksManager assumes that the wiring location
points to unpacked blocks, implement support for packed blocks.
I think these are the main issues.
/Daniel
