You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Guido Casper <gc...@s-und-n.de> on 2004/04/02 08:34:32 UTC
Repository (was Re: Linotype)
Rolf Kulemann wrote:
> On Sat, 2004-03-27 at 16:31, Guido Casper wrote:
>
>>Concerning the repository ... I just committed another repository
>>interface :-) that tries to be a best effort in consolidating all the
>>different approaches and accommodating all concerns in a flexible way
>>(by having opional helpers for property management, versoning and
>>transaction management).
>>
>>Like suggested in this thread
>>http://marc.theaimsgroup.com/?t=107022316500003&r=1&w=2
>>
>>the approach does not intend to build upon the source interface but to
>>provide an interface for different repository implementations (on top of
>>which a RepositorySource might be implemented).
>>
>>I'll try to come up with a first cut of an implementation for a WebDAV
>>repository by the end of next weekend.
>
>
> Cool.
>
> We in the Lenya land also plan to "use a kind of repository". We tried
> to gather all our repository interface requirements in
> http://wiki.cocoondev.org/Wiki.jsp?page=LenyaRepositoryRequirements .
>
> The last days I played around with the slide block. For example I used
> the SlideSource and the repository block to save and read from slide.
>
> The main lack of the repository interface or slide source was:
>
> - How to access versioning functionality
>
> I see two obvious approaches:
>
> 1.) Directly use the interface VerisonableSource which is implemented by
> SlideSource or use the Repository interface to create new versions etc.
> The problem is
> * The repository interface supports no methods for versioning
> * SlideSource does implement the VersionableSource but the appropiate
> method bodies are quite empty.
>
> What interests me is:
>
> What do u plan for versioning regarding the repository interface?
There is a RepositoryVersioningHelper interface which may serve as a
starting point for most versioning needs.
>
>
> FYI:
>
> In Lenya land we tend to use JCR in the future and think about using
> Slide somehow now. I think the best would be to isolate slide/jcr by a
> repositroy layer in cocoon. Of course WebDAV plays a role , too. I can
> imagine WebDAV under JCR or a raw WEBdav based repository
> implementation.
>
> 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)
-link management
-a RepositorySource(2)
I would be interested what Lenya land (and others) thinks of such an
approach.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Repository
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-02 at 17:20, Guido Casper wrote:
> Rolf Kulemann wrote:
> > [...]
> > A very important question for me:
> >
> > When can there be some alpha code seeds available in cvs?
> >
> > I saw there is sth. changing already in the repository block.
> > I'm especially interested in versioning of the rep. sources.
>
> I just committed an impl for WebDAV. It needs completion and more
> testing (I'll come up with samples later).
Guido, I very much like what you checked in the otherday.
I directly started to do a "personal" sample with your WebDAV repository
impl.
Thanks very much.
--
Regards,
Rolf Kulemann
Re: Repository
Posted by Guido Casper <gc...@s-und-n.de>.
Rolf Kulemann wrote:
> On Fri, 2004-04-02 at 11:40, Guido Casper wrote:
>
>>>>-link management
>>>
>>>
>>>What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
>>>explain your idea in more detail.
>>
>>I'm thinking of managing linking information within metadata/properties
>>in a bidirectional way so that broken links may be prevented/detected
>>early on in the authoring process.
>
>
> Mmmh. Ok, I understand your requirement. I thought, if we use "hrefs"
> like "site:..." and the LinkRewriter we do not need to care about broken
> links etc, since we refer to a symbolic href target in docs only. We
> only need to maintain the link db for the LinkRewriter which itself (the
> db) is a doc in the repository.
>
> Does that make sense?
Yes I think LinkRewriter is nice for many use cases. But it doesn't
answer what happens if you delete a document being linked by another
document. And I'm unsure wether maintaining a central link db is a good
way to do this kind of link management. I see LinkRewriter somehow
orthogonal to what I have in mind.
But currently it's not much more than an idea (there is no code) and I'm
interested to hear other opinions.
>
>
>
>>>>-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?
>>
>>No, I mean a Source implementation implementing all the needed
>>subinterfaces while operating only on the Repository interface
>>(currently lacking getChildren() etc. for the traversable stuff). So
>>that not every repository needs to implement its own Source.
>
>
> Ah, ok.
>
>
>>For a particular repository, implementing the Repository interface may
>>in summary be the same amount of work (although you may be less
>>distracted by the special semantics of Sources), but you get more
>>functionality (and better testability) and the Source implementation
>>comes for free.
>
>
> Ok.
>
>
> A very important question for me:
>
> When can there be some alpha code seeds available in cvs?
>
> I saw there is sth. changing already in the repository block.
> I'm especially interested in versioning of the rep. sources.
I just committed an impl for WebDAV. It needs completion and more
testing (I'll come up with samples later).
However I'm currently not working on a RepositorySource.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Repository
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-02 at 11:40, Guido Casper wrote:
> >>-link management
> >
> >
> > What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
> > explain your idea in more detail.
>
> I'm thinking of managing linking information within metadata/properties
> in a bidirectional way so that broken links may be prevented/detected
> early on in the authoring process.
Mmmh. Ok, I understand your requirement. I thought, if we use "hrefs"
like "site:..." and the LinkRewriter we do not need to care about broken
links etc, since we refer to a symbolic href target in docs only. We
only need to maintain the link db for the LinkRewriter which itself (the
db) is a doc in the repository.
Does that make sense?
> >>-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?
>
> No, I mean a Source implementation implementing all the needed
> subinterfaces while operating only on the Repository interface
> (currently lacking getChildren() etc. for the traversable stuff). So
> that not every repository needs to implement its own Source.
Ah, ok.
>
> For a particular repository, implementing the Repository interface may
> in summary be the same amount of work (although you may be less
> distracted by the special semantics of Sources), but you get more
> functionality (and better testability) and the Source implementation
> comes for free.
Ok.
A very important question for me:
When can there be some alpha code seeds available in cvs?
I saw there is sth. changing already in the repository block.
I'm especially interested in versioning of the rep. sources.
--
Regards,
Rolf Kulemann
Re: Repository
Posted by Guido Casper <gc...@s-und-n.de>.
Rolf Kulemann wrote:
> On Fri, 2004-04-02 at 08:34, Guido Casper wrote:
>>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?
Yes, just have some kind of "WorkflowObject" that serves as a decoupling
adapter between workflow and repository so that workflow can be used
with other components as well.
>
>
>>-link management
>
>
> What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
> explain your idea in more detail.
I'm thinking of managing linking information within metadata/properties
in a bidirectional way so that broken links may be prevented/detected
early on in the authoring process.
>
>
>
>>-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?
No, I mean a Source implementation implementing all the needed
subinterfaces while operating only on the Repository interface
(currently lacking getChildren() etc. for the traversable stuff). So
that not every repository needs to implement its own Source.
For a particular repository, implementing the Repository interface may
in summary be the same amount of work (although you may be less
distracted by the special semantics of Sources), but you get more
functionality (and better testability) and the Source implementation
comes for free.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Repository (was Re: Linotype)
Posted by Rolf Kulemann <ro...@apache.org>.
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