Definitely agree with Remy on this. About a year ago, I examined Avalon quite a bit. The IOC part is very nice, but the framework is a bit too heavy IMO.
Maybe Spring or PicoContainer would be worth examining instead. If Slide2.0 is becoming close, it would be a bad idea to change too much now. I'd say do a beta or RC1 as soon as possible, remove the bugs, and then create the official release. Then it could be a time for considering using another framework (Avalon, Spring, Pico). Actually I thought that this project was more or less dead, good to proven wrong. Anyway I can help? Kent Remy Maucherat <[EMAIL PROTECTED]> wrote: > Edison Too wrote: > > Hi, > > > > I agree with Stefano's observation that there is a need > for a good > > content repository. I've looked into Slide's code before > and I can't > > help but wonder if it is a good idea for Slide to be > implemented > > using Avalon. > > > > The server core can be broken down into 3 blocks 1. > Content > > repository (store?) 2. User management 3. Access Control > management > > These are very useful/essential component which are > (AFAIK) strangely > > missing in the current crop of Avalon > Components/Services. > > > > Advantage of migrating : 1. Reuse of Avalon components > such as > > configuration/connections/pooling/logging etc. 2. > Deployable as a > > standalone or servlet using Fortress or Phoenix. 3. If a > Cache block > > comes along (from Cocoon maybe?) it can be reused in Slide > to improve > > performance. 4. Attract more developers from the land of > Avalon or > > Cocoon. I think it will open up a lot of possibilities. > Think of it, > > with James, Slide, Cocoon, interesting server apps can be > built. > > > > I know it's not easy to switch and most developers dread > such a big > > change especially when r2.0 is in view. This is just a > thought I feel > > worth discussing, especially when Stefano says he will > investing his > > time into Slide. > > > > I'm not an expert with Avalon, but I'm willing to invest > some time if > > this the direction Slide decide to pursue. > > > > Thoughts? > > If I was still involved in this project, the answer would > be: of course not. > Avalon provides a set of utility components which all seem > inferior to > what is available in the commons without any strings > attached, and as a > result, I've been very careful to avoid using it. > As for deployment of "blocks" or "services" (if you really > need it in > this case), a JMX based model (using commons-modeler 1.1, of > course) is > immensely more flexible, introduces almost zero coupling in > the > application, and is standards based. > > Of course, Slide committers are free to decide to do > whatever they want :) > > R�my > > > > ------------------------------------------------------------ > --------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
