cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Kulemann <>
Subject Re: Repository (was Re: Linotype)
Date Fri, 02 Apr 2004 07:19:35 GMT
On Fri, 2004-04-02 at 08:34, Guido Casper wrote:
> Rolf Kulemann wrote:
> [...]
> > 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)

Good point. For workflow info is expressed through metadata/properties I
bound to "document" stored in a repository. At the mom Lenya uses a set
of xml to express workflow states etc. which is also somehow bound to a

Of course workflow is needed, but has nothing to do with the repository.
The repository interface should simply enable annotating "docs" with
appropiate wf metadata/properties.

Makes sense?

> -link management

What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
explain your idea in more detail.

> -a RepositorySource(2)

I thought of that, too. Please explain your idea in more detail :)

So u want users to act on a RepositrySource instance instead of the
single interfaces like TraversableSource and VersionableSource for
example? Would make sense. That would mean every "source provider"
should implement a RepositorySource/Factory?


    Rolf Kulemann

View raw message