> > > > > 3) The entire services layer will be deprecated. A new method of > > > accessing the components will be used to replace the old > > functionality > > > that the services layer provided. > > > > Then I assume you are talking about the use of Fulcrum in > > Turbine-2. If so the static accessor mode needs to go away. > > > > Not really. > > We have users that have written their own services. I would like for > these services to continue to function in Turbine 2.3. We could > deprecate all of the services layer though. The next version of Turbine > *might* have the services layer completely removed.
If we are promoting the use of Fulcrum with static accessors in the 2.x series then I'm -1 on the whole idea. The waters are already muddied with code being backported from Fulcrum to the services in 2.x. The services in Fulcrum should go wholly to being real Avalon services using the correct method of composition. In the 2.x series the old services should be used. If people want to continue using 2.x then they use the services that come with 2.x. If it is decided to put a container into the 2.x series then that's fine but the Fulcrum services should be used properly. The static accessors lead to very bad code. So just to be clear: I'm -1 on promoting the use Fulcrum with static accessors in the 2.x series. It just makes things a bigger goat fuck than they already are. Leave people with their services working in 2.x. If they want to use Fulcrum services, which should become Avalon services with XML configuration and the elimination of static accessors, then they use them correctly. For the relatively few people using Fulcrum in production they can move forward to using an XML configuration. It's already a morass, I don't believe grafting in hacky Fulcrum services into 2.x is going to make it any better. > Fulcrum could have its services layer along with the static accessors > completely removed. If Fulcrum is going to be strictly a collection of > components, this would make sense. Yes, this is exactly what should happen. > Optionally, we could just deprecate the services layer in Turbine to > prevent breaking any existing code. The second release of Fulcrum > could have the services layer removed. "Services layer in Turbine" ? Are you talking about the service code in 2.x? If so that should be left alone completely or you're really going to hose users. Leave that code entirely alone, plugin in a container if you like and use components as they should be. Other parts of your application model will use the service manager to assemble various components. Leave the old as the old, use the new as the new. I think jacking around with the 2.x service code is very bad and dangerous idea. The 2.x service code should be left there forever because there are definitely tons of services based on that code and there's no point in deprecating it when they can be used in conjunction with real avalon services. > I know this is just keeping a problem around longer than we might have > to. Personally, I don't use Fulcrum and I suggest to users that they > not use fulcrum at this time. Changing Fulcrum like this might not be > an issue. I am sure that by the time this discussion is over, we will > have heard from anyone that has an issue with this idea. I agree that Fulcrum shouldn't be used in 2.x code. So why are you pushing this? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
