> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 27, 2003 2:17 PM > To: Turbine Developers List > Subject: RE: Turbine, Fulcrum, and Avalon > > > > > > > > > > 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
No. Fulcrum can be accessed properly through a container/service manager setup. > > 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. Agreed. > > 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. Agreed. > > 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 I meant to say "Services Layer in Fulcrum". This was only for the benefit of current Fulcrum users. I don't even know if there are any besides Scarab. Perhaps it is a complete non-issue. > 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. Agreed. > > > 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? > I am not saying that Fulcrum should not be used in 2.X code. Perhaps we should let this start happening with 2.3. I don't see the point in maintaining two code bases for the services. I have been working on enhancing several of the coupled services for Turbine 2.3. At some point, we are going to merge those changes back into Fulcrum. If that is going to happen, I would rather start using Fulcrum than continue working on the coupled services. I have not been in the development process of Turbine but for a few months. All that I really know about is the immediate plans is Turbine 2.3. There have been very few discussions (only a few mesasges or so) in the past months even hinting at where we might go after 2.3. I think that by putting a container in 2.3, we will make the path to Plexus (assuming we adopt Plexus as a future version of Turbine) much less painful. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
