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
