Reinhard Poetz wrote:
Ralph,
I can't follow your argumentation anymore. How do the following
statements fit together?
"Please provide an example of what this would look like. I really need to
understand how this will simplify anything."
and
"And I don't see much point in learning how trunk works until it
stabilizes."
This is pretty simple. I'm tired of long emails about theoretical
topics. I frankly can't understand what the heck you guys are talking
about half the time because I never see any concrete examples in the
emails. I just can't give an honest to goodness answer as to whether
this is a good thing or not without something I can wrap my arms
around. And looking at trunk to figure it out doesn't seem to be a
productive way to do it as I have come to believe that trunk is never
going to be released. (This is my opinion - you certainly don't have to
agree with it or like it).
... so what do you want? Daniel and I spend our spare time on
improving trunk and this takes time as nobody is paying us directly
for this because we do it in our spare time. We have a clear goal and
we communicated it dozens of times to the list and added all open
tasks to JIRA.
If this is too slow or insufficent for your needs, you need to get
involved by getting your hands dirty. You're complaining that things
in trunk don't work as they should? Hey, that's your chance! I don't
think that it's rocket science to improve things.
I also get paid to do real work. OSGi doesn't fit in those plans. A
lot of other stuff in trunk does but I can't have it because a release
of trunk isn't going to happen in 2006. My employer won't pay me to
work on stuff that they won't see in the next few months. And there is
enough stuff in 2.1 that needs fixing to keep me busy for a long time.
- o -
*If* you had took the time to learn a bit more about the architecture
that Daniel is proposing, you would learn that our work on OSGi isn't
affecting the non-OSGi-Cocoon in any way. Look at the current way of
setting up Cocoon:
"[...] The CocoonServlet creates a CoreUtil which creates a
CocoonBeanFactory which in turn is used to get the Cocoon component,
which in turn delegates most of it job to the SitemapLanguage which
also is a component that is managed by the CocoonBeanFactory. A fun
exercise for the interested is to try to figure out how and where the
Cocoon component is configured and created. [...]"
Daniel's proposal was about making this process simpler and this has
*nothing* to do with OSGi. Daniel and I believe that OSGi is the way
to go but this doesn't necessarily mean that everything we do is
OSGi-related. As we had to understand Cocoon internals in greater
detail, we started to think more and more about how to simplify
things, and believe me, there is room for improvment as the core of
Cocoon has grown and got too complicated over the years.
Well, I apologize for not knowing enough about trunk to understand that
that is how it all works now. However, I'd still like to see an example
of how configuring via a servlet filter will make the configuration
simpler. Or does it just make the code simpler?
Ralph
