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).
Exactly.
>
> 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
document.
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?
--
Regards,
Rolf Kulemann
