Sylvain Wallez wrote: > I asked Carsten why he doesn't want to use the bridge that _he_ wrote, > and would love to have his answer. Carsten? > Now all this comparing of the things Apple did with our situation is missing imho a big difference: Apple decided that their next OS (MacOS X) should have this and that feature and *then* they thought about a possible bridge for old stuff. So first they had a plan on what to build next (without taking old stuff into consideration). Even more important the bridge is a connection from the new stuff to the old one.
Currently we are discussing the opposite! We say, we have this nice bridge that allows the user to use anything (Spring, Pico, Hivemind) she likes and this bridge is a connection from our old stuff (we want to get rid off btw) to new stuff. So, we don't have a clear plan on what the new version should be and just leave it to the user. This would be like if Apple had said, oh, we still use MacOS 9 and provide "bridges" for windows, linux and AmigaOS. See the difference? And this is why I don't want to use the bridge in general. It's the wrong way. The bridge is nice if you want to use Spring etc. with Cocoon and want a tighter integration. But with the bridges the core will never change, it will still be ECM++. And the current bridge has some other problems, it does not provide access to everything required and I think it might have a performance problem if used the wrong way. Now, actually, I wanted to have constructor injection and more simplifications to make working with the portal block easier. As the portal block in theory has no real connections to cocoon - it's a set of components triggered by a generator - I think I'll use a different approach there, like embedding Spring directly into the generator and building the whole portal on top of Spring without using anything of Avalon. Other portal relevant projects are using Spring anyways, so it might make sense to go into that direction as well. But I fear this approach will not work for other blocks. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
