[snip...] > > > 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?
I think we need two different types of locks in slide: First there are webdav-locks that should be acquired/released transactional. This means that it should be possible to acquire a number of locks in one transactional and rollback the whole transaction when a single lock fails. Bedides this there is a need for internal global locks that handle concurrents modifications. Think of two copy operations in different transactions where every user wants to to copy to the same target. At the moment this is delegated to underlying stores in a not very beatyful manner (recursive read)... Olli will start a thread on this to discuss this in more detail. > > > - 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] First and most easy would be to disable caching :-) If caching is enabled, it must be ensured that the cache is always consistent. At the moment there a some places, where for example invalid data remains in the cache if a transaction is rolled back (have a look at StandardStore). So the store must be transaction-aware. Olli has implemented transactional caching in extended store, this is the way to go. But permission caching is still broken. This is not that worse, because the cache resides in SlideToken - that means that the cache will be per user and is getting recreated every request. This should be improved. > > > - (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? I will post on this issue later. The events must be transaction aware as well (some need to be sent after commit, some may be needed before to enable vetoable changes). There should be a number of internal events and the possibility to generate custom events for example inside an interceptor. In our product we used events not only for caching, but also for synchronizing the editors swing clients by pushing events to all client. This is a very nice feature, because the client users can see in realtime what other editors do and navigation on the website can be synchronized with the clients navigation. > > > - Implement fast searching capabilities (properties and full text search, > > perhaps using lucene) > > that would be cool. How pluggable is the DASL implementation? Don't know yet. At the moment the stores are responsible for search. There is for example a XQuery engine in the tamino stores that can be triggered via DASL as far as I know, but this is of course not part of slide... > > > - 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. Agreed. > > > 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. Yes, but personally I'm responsible for providing a CMS product wich is used in our company. So I have to care about the other things as well and can't distribute that much at the moment... Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
