cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Casper <>
Subject Re: Status of repository block and webdav question.
Date Wed, 19 May 2004 11:28:56 GMT
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
>>>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 Casper
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5
D-33100 Paderborn

View raw message