Eric Dobbs wrote: > On Thu, 2002-07-25 at 12:38, Henning P. Schmiedehausen wrote: > >> while the idea is cool, I'd prefer to get the fulcrum stuff to >> actually work with T2 and T3 and then migrate a stable code base. The >> current fulcrum code base is "preliminary" at best... :-) >> >> Please allow us to make at least one Fulcrum release before migrating >> to yet another platform... > > > I agree with Jason and James. > > -0 for release of Fulcrum. > > I'd be -1 except I'm going to be gone for most of August > and don't have time to fight about it between now and > when I leave. Nor do I have time to work on an > alternative. So I won't block a Fulcrum release, but > I'll ask really nicely. Please, please don't release > Fulcrum. > > Here's why I'm opposed to it. > > As I said on turbine-user earlier this week, I think the > decoupling of Fulcrum from Turbine 2 reveals that the > "services" are really "components". > > <tangent name="definition of terms"> > "services" are larger grain business services that an > application offers to external systems. Fulcrum's > services are mostly there to serve the internal needs > of the application -- localization, database pooling, > file upload, scheduling. Those are "components", not > "services". XMLRPC is also a component 'cos it's > there to support an external interface, but it isn't > a service in-and-of itself. > </tangent> > > Avalon does components much, much better. It won't > be hard at all to implement the Avalon lifecycle > interfaces. > > Also, we (me included) have done a fairly poor job of > supporting Fulcrum to date. I don't see a release > helping matters. I also think it's not appropriate to > release something if we intend to abandon it, or if > some of the developers are unwilling to support it. > > I'd rather see the energy spent implementing Avalon's > lifecycle interfaces and getting Plexus integrated with > T2 and released.
+1 :-) > It's probably slightly more work than getting Fulcrum > working with T2. But it's a much bigger payoff -- we > and Avalon would be able to share components. Wow, this is really the best part, AFA I'm concerned. Cool, cool, cool :-) >> Personally, I'm a little scared about "being run over by Avalon". :-) >> >> And in search of docs, I'm upset by links like this: >> http://jakarta.apache.org/avalon/phoenix/what-is-a-block.html ... %-) >> (So, can anyone actually tell me what a block really is?) > > > I would ignore Phoenix and Blocks. It's not that they aren't > interesting, just not what Turbine needs. We just need to > implement the component lifecycle interfaces and make Plexus > work. As I said on the user list earlier this week, Avalon is > about components and about containers that compose and control > the components. We can focus on the framework and the > lifecycle interfaces and not worry about whether Blocks are > well defined. *Definately*. Avalon is the Framework. The Framework is rock solid and well tried and tested. The rest are implementations. They are cool, some are more stable than others, but we are still moving towards a common vision on the implementations. >> ATM I don't see no reason why any component of Fulcrum should be >> dropped. Maybe the db service, because it is no longer necessary. > > > Agreed. The components (except db) stay, with a little refactoring. > The Fulcrum framework gets replaced by an Avalon container. Yup. Don't throw away anything, just start to use the Framework, and the rest will come natural :-) Yeah, eventually we will have Catalina, Turbine, Cocoon, all working under a newly-born Phoenix and sharing components seamlessly.... eventually... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
