cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The environment abstraction, part II
Date Thu, 02 Feb 2006 10:31:57 GMT
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.


>>> 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 ( 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 

* 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.


View raw message