It's nice to have you around on this list Stefano, you're able to point out things very clearly.
Thanks.
I'm propagating the idea of moving from a CMS to something like a CMF in our company for quite a while.
But I think that Slide should be more than just a content repository. If we don't provide some bundled CMS build on top of slide (JSP-based, Cocoon-based or whatever), many people don't see the potential of Slide.
Very true, but wheter or not this is Slide's direct concern, this is another story.
It would be like saying that you have to ship Tomcat with a big servlet (say Cocoon) otherwise people would not understand the power of servlets.
I think it's better to have each project focus on what they do best (repository for Slide) and let others build applications with it.
This is called "separation of concerns". It allows faster parallelization and increases scalability of the entirey development process.
But first we have to get Slide running as a content repository and it's still a way to go.
Yes. I think this is what we should focus on. The community, out of environmental pressure, will decide what to do later.
My favorit issues are: - Getting the stores to work as expected (at least file/db-stores)
this is critical, yes.
- Implement internal locking (should not be transactional)
can you tell us more about this?
- Improve and fix caching. It's not fully transactional in some places and can be improved (especially lock/permission-cache)
same here, do you have any idea on how to do this? [curious]
- (lateron) real XA-support to use different stores (a great feature of slide) in one transaction
ah, nice.
- Extendable event mechanism (that is essenital for 'inverted caching' in the presentation layer or to distribute changes in a clustered environment)
big +1, what do you have in mind for this? interceptors?
- Implement fast searching capabilities (properties and full text search, perhaps using lucene)
that would be cool. How pluggable is the DASL implementation?
- Internal link checking (so that if you check out some revision of a document that uses others you're informed and get the choice to check out the used documents in the right revision as well). I don't know, if the current content interceptor concept allows such a feature as an optional module, otherwise it should be improved to allow something like this.
I would say this is application-dependent. I agree that the repository should provide the ability to implement the above functionality, but it should not be something that the repository gives you directly... otherwise you blur the line between the repository and its semantics... and this is a path I wouldn't want Slide to see going.
On the other hand I still won't drop my idea to donate our rendering/process-engine (maybe into proposals-section) and implement some demo-project to give users a better starting point and a full featured framework to implement projects. But I see that this have to be discussed.
I say we focus on getting the repository out solid, fast and clean, then we'll see what happens.
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
