cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Micro kernel based Cocoon
Date Mon, 23 May 2005 08:13:27 GMT
Sylvain Wallez wrote:

> Reinhard Poetz wrote:
>
>> AFAIU only some work on cForms is missing (flowscript API and 
>> repeater binding)
>
>
>
> That's far from the only work to do IMO, as there are a lot of 
> semi-finished core features. Some that come to mind: refactored object 
> model,

Here the main problem is that JXTG and flow have some differences in 
behaviour, see http://marc2.theaimsgroup.com/?t=111648265000001&r=1&w=2 
and 
http://marc2.theaimsgroup.com/?l=xml-cocoon-dev&m=111666682531907&w=2 
for description and possible solutions. We need to decide: should we 
keep trhe direct access of request params as properties of 
cocoon.request and session/context attributes as properties of 
cocoon.[session|context] or not. Should we support the direct usage of 
org.*, javax.* and com.* whithout needing the Packages. prefix in flow?

Is there anythimg more?

> sitemap listeners,

> VPCs,

I'm waiting for community involvement.

If we follow Vadim's suggestion 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111331073205551&w=2, 
nothing in core need to depend on vpc code and the vpc code could be 
mocĀ“ved to an own (unstable) block.

> third-party containers, etc. Not that these features don't work, but 
> they lack (at least that's my impression) some more use cases and 
> demos to be strong enough for a stable release.
>
> Sure, we can make an alpha release to give people a sign that we are 
> doing some progress, but this should be for us the sign that no more 
> features should be added in that branch.

As discussed in the relases thread I don't think it is realistic to stop 
adding features, we need a way to let rock stable core functionality 
coexist with new features. Otherwise the defacto "no release" policy 
will continue.

/Daniel


Mime
View raw message