cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] Converging the repository concept in cocoon
Date Sun, 30 Nov 2003 20:11:43 GMT
I'm working on Doco and I finished my first phase: I have a repository 
that I like and does what I need. It's Slide, in case you haven't 
noticed ;-)

So, now I have a WebDAV/DeltaV/DASL/ACL repository and I want to 
connect to it.

There has been a lot of work in the area of "Repository API" lately, 
both inside and outside cocoon.

Cocoon currently hosts four different repositories concepts:

  1) two in the linotype block
  2) one in the slide block
  3) one in the repository block (which is a refactoring of the 
SourceRepository in linotype)

the linotype repository is a big time hack: it does what linotype 
needed, but it's not reusable outside (concerns overlap in its 
interface). The SourceRepository is an implementation of the linotype 
Repository over a source instead that over a file system. While nicer, 
it inherits all the problems of the original interface. It does 
versioning but it doesn't do properties or property querying.

the repository in the slide block uses slide directly and, mostly, for 
authentication purposes... it's based on an older version of slide, 
doesn't handle versioning, doesn't handle file properties. It's based 
on actions, generators and transformers. To me, looks old and the need 
to have the repository on the local machine (and keep it opaque to the 
outside world) makes it impossible to use in what I need.

the one in the repository block is the cleanest one, but IMO, its 
design is backwards. I'll explain what I mean in a second.

For now, I think it's a must that, just as we did with forms, we take a 
look at the various approaches and choose one to follow and ignore the 
other ones.

I think the repository block is the best effort, but it needs 
substantial redesign.

                                          - o -

First of all, let me introduce what I mean with a "repository".

A repository is a place where I store my content.

Functionality I need is:

  1) open/save document
  2) create collection of documents
  3) attach metadata to documents (externally to them!!)
  4) query the repository against document metadata
  5) versioning (autoversioning on saving and version update)

how all these functionalities are implemented should *NOT* be my 
concern, nor I want it to be when I'm using the repository.

The linotype repository uses this design, while the one in the 
repository block does not.

Why not? well, it's fully based on sources and tries to obtain the 
above functionalities from the source abstractions. This means that the 
contract is not on the API but on the source URL.... but this also 
means that we cannot fully separate concerns since it's the driver of 
the repository who chooses which source the repository needs to write 
on.

I strongly dislike this design because I think it got it all backwards: 
it should be the Repository to implement Source and give source access 
to those components who want to access content (say a FileGenerator or 
even a TraxTransformer)

I looked into the repository block and I find a *lot* of things 
(locking, permissions, properties) that look very much like a 
duplication of effort. The Slide project spent years optimizing and 
polishing issues like transactionality and locking, do you really want 
to implement a layer to "emulate" those things in case the given source 
is not capable of handling it itself?

I think a much better approach would be to come up with a

  Repository.java

interface and a few implementations that I can choose when I install 
cocoon. This implementation would also implement Source.java and 
provide its functionality thru a URL protocol.

This allows:

  - clear separation of concerns: cocoon should *NOT* be doing 
repository stuff, which is already big and complex enough

  - complete IoC: you choose the implementation and the implementation 
decides what to do and how to do it. Your contract remains the same 
(thru the source-provided URL protocol and thru the component 
interface)

  - transparent polymorphism: you can have different implementations of 
a repository... file system, webdav, CVS, JCR, ... without having to 
change any code in your application

Thoughts?

--
Stefano.
Mime
View raw message