Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
Question is is there an interim "thing" that we can release before whole
OSGi is implemented? We were talking about an RC when Maven build was
done, but we seem to be moving away from that.
Sure there are a number possible interim things.
We can release more or less as is, what is lacking is a Maven
correspondence of the block.properties file and a plugin that collect
and install the configuration snippets in the blocks to the webapp.
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.
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.
Gradual steps, release often is good.
Agree, but as it will be the first release from trunk the threshold is
higher.
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?
...
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.
But that is IMHO, if enough people are prepared to make a 2.2 happen, I
will of course join in that work.
Again - define what 2.2 is. At the moment, these are just numbers. We
should be taking about whether we are going to release feature sets, not
numbers.
You are right, I was referring to the first alternative above, i.e. more
or less as is.
So the main question is if enough people are motivated to work for
making that happen. I'm not particularly motivated in working for
keeping life in the monolithic beast for another minor version series. I
rather work without releasing for a while and release something that I
will feel proud to be part of.
Again, if there is a momentum for an "as is" release I will of course
respect that.
Now, we have currently two other environments: cli and portlets. A
portlet is a web application, so there won't be any problem. And for
the CLI we can come up with some kind of HttpClient that internally
starts Jetty etc.
Yes. For CLI an alternative is to have a minimal servlet container as
part of the CLI. Maybe its possible to use Jetty in that way without
needing to go over a socket?
Why a servlet container? Or do you mean simple implementation of the
servlet interfaces? That would be what we would need. Something to set
up request and response and call the servlet's service() method.
I mean a simple implementation of the servlet interfaces as you suggest.
I haven't studied the CLI implementation in any detail, what is your
opinion about letting it work on the servlet interfaces rather than at
the Processor level. What consequences will it have?
Wouldn't be too hard. It builds its own Request, Response and
Environment, and a Cocoon object to use. Moving it across shouldn't be
too hard (although the CLI could do with a _serious_ rewriting, but
that's for other reasons).
It seemed that it hasn't been refactored for a while. Much of the setup
work will not be needed anymore if it call the rest of Cocoon at the
servlet level rather than the processor level.
/Daniel
