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. 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. > 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. > 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. -Eric -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
