Rolf Kulemann wrote:
On Wed, 2004-05-19 at 09:10, Guido Casper wrote:
Rolf Kulemann wrote:
What u mean with Repository block? IMHO there are currently two approaches hosted within the repository bloch, which should be divided normally.
1.) SourceRepository which acts on various interfaces like
VersionableSource etc.
2.) Repository interface with a WEbDAV _only_ implementation which is too flow oriented (no exception handling etc.)
These 2 (interfaces) are not all that different (like different approaches) and I plan to merge them.
Sorry, but they are different to me. Repository acts on String like paths and exposes services. The SourceRepository just acts on services exposed by the various *Source interfaces. That looks to me like two different approaches.
The only indication (within the interface!) of the fact that the implementation acts on Sources is the name and the throwing of SourceExceptions. As a client of this component you are just giving URI Strings to it.
But yes there is a conceptual clash between implementations and if you want a grand unified Repository concept, you have to decide between:
-having one Repository acting on different Source implementations
-having (one source acting on) different Repository implementations
I (obviously) opt for the latter.
I'm curious about ur concrete merging thoughts. Would be cool if u share ideas :)
-First, the SourceRepository currently ignores Properties.
While preserving Unico's exciting work on SourceInspector (as was Stephan Michel's work before) and SourceDescriptor I would like to move the setting of properties and the like away from the pipelines into the SourceRepository itself (while preserving a working davmap sample). From there on merging the interfaces should be quite straight forward.
-The second thing is that the SourceRepository acts on absolute URIs while I prefer paths relativ to some configured repo root.
-Furthermore the SourceRepository is geared towards *serving* WebDAV (i.e. managing HTTP status codes), a fact that probably shouldn't be within a generalized Repository interface (although serving WebDAV probably is a great use case for a repository).
Keeping the implementation of SourceRepository (working with the SourceDescriptor) is certainly worth it as it provides a lightweight (and still kind of universal) repository for simple needs (without versioning etc.) in the filesystem (or other simple Sources not available as complete repositories). Once a SourceImpl acting on instances of Repositories is available the current RepositorySource might be deprecated.
These are the things (in addition to the JSR170 issue) to address IMO. I planned to bring them up for discussion when I have time to work on them (which is not the case currently :-).
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
-------------------------------------------------