On Sat, 2004-03-27 at 16:31, Guido Casper wrote:
Concerning the repository ... I just committed another repository interface :-) that tries to be a best effort in consolidating all the different approaches and accommodating all concerns in a flexible way (by having opional helpers for property management, versoning and transaction management).
Like suggested in this thread http://marc.theaimsgroup.com/?t=107022316500003&r=1&w=2
the approach does not intend to build upon the source interface but to provide an interface for different repository implementations (on top of which a RepositorySource might be implemented).
I'll try to come up with a first cut of an implementation for a WebDAV repository by the end of next weekend.
Cool.
We in the Lenya land also plan to "use a kind of repository". We tried to gather all our repository interface requirements in http://wiki.cocoondev.org/Wiki.jsp?page=LenyaRepositoryRequirements .
The last days I played around with the slide block. For example I used the SlideSource and the repository block to save and read from slide.
The main lack of the repository interface or slide source was:
- How to access versioning functionality
I see two obvious approaches:
1.) Directly use the interface VerisonableSource which is implemented by
SlideSource or use the Repository interface to create new versions etc.
The problem is * The repository interface supports no methods for versioning
* SlideSource does implement the VersionableSource but the appropiate
method bodies are quite empty.
What interests me is:
What do u plan for versioning regarding the repository interface?
There is a RepositoryVersioningHelper interface which may serve as a starting point for most versioning needs.
FYI:
In Lenya land we tend to use JCR in the future and think about using
Slide somehow now. I think the best would be to isolate slide/jcr by a
repositroy layer in cocoon. Of course WebDAV plays a role , too. I can
imagine WebDAV under JCR or a raw WEBdav based repository
implementation.
Important is imho, that all "repositories" are isolated by a common repository interface.
Yes I intend the Repository interface to be a (low level) facade into different kind of implementations like slide, jcr, webdav or an extended version of the current SourceRepositoryImpl (so you can run samples with nothing but the filesystem and HSQL).
It feels easier to manage and to use than to squeeze everything through the Source interface - at least for modifying operations. For read access Sources of course have it's use and the Source/Repository combo seems to be a powerful concept.
On top of this other higher level components might be build. Among the things I have in mind are:
-a document store accommodating a certain array of use cases and being simple to use from the flow layer (in fact there might be different kinds of document stores being shielded from the particular repository implementation)
-a workflow component (although that shouldn't be bound to the repository)
-link management
-a RepositorySource(2)
I would be interested what Lenya land (and others) thinks of such an approach.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------