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]
