cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Kulemann <m...@rolf-kulemann.com>
Subject Re: Status of repository block and webdav question.
Date Wed, 19 May 2004 12:22:44 GMT
On Wed, 2004-05-19 at 13:28, Guido Casper wrote:
> Rolf Kulemann wrote:
> > [...]
> > 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.

Ah, now I got u, sorry.

> 
> 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.

ok.

> 
> > 
> > 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.

Sounds like a plan.

> 
> -The second thing is that the SourceRepository acts on absolute URIs 
> while I prefer paths relativ to some configured repo root.

+1

> 
> -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).

Of course not.

> 
> 
> 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.

Ok. So u will keep URIs as Strings being passed as args to the
repository interface ?


Do u mean a source to act on the reps like this ? :

------------------------------------------------
|RepositorySource                              |
------------------------------------------------
|Repository                                    |
------------------------------------------------
|SlideRepository|WebDAVRepository|JCRRepository|
------------------------------------------------

What about all the *Source interfaces like i.e. VersionableSource and
TraversableSource ? Should they be implemented by RepositorySource ?

How would the protocol of RepositorySource work?
I guess u plan that is possible to configure different reps. with
different "symbolic names". So, what url should be used i.e. in sitemaps
to access a rep source?

I.e. imagine three rep. definitions a, b and c where a and b are
pointing to the same backend but using different uri prefixes i.e. x and
y. a id configure with prfix z

Lets see how that could work in a sitemap:

<map:generate src="a:/mypathrelativetox"/> and
<map:generate src="b:/mypathrelativetoy"/> and
<map:generate src="c:/mypathrelativetoz"/>

In all cases a RepositorySourceFactory would create a RepositorySource
which looks up the right repository impl. in order to
delegate/fullfill/execute services??

> 
> 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 :-)

Good to know. Thanks for the info.

-- 

RolfKulemann

"There is inherently no silverbullet" - F.Brooks


Mime
View raw message