On 3 Dec 2003, at 12:14, Andreas Hartmann wrote:
Stefano Mazzocchi wrote:
[...]
Well, yeah. I thought JCR was supposed to be this "Repository.java"? WhyI think so, yes. JCR is incredibly powerful, but exactly because of this power, it feels a little "low level". JCR is sort of a virtual hypergranular file system with multidimensions. Think of it as a persistent DOM with enhanced serializing and query functionalities.
not just use that? Do we really need another layer?
I think you will always need a sort of "application oriented API" on top of JCR... just like you need business objects on top of a relational database.
On lenya-dev there are some discussions about switching from java.io repository access to an abstract repository API. We considered JCR, but if there will be another application-oriented API for Cocoon above JCR in any case, this would certainly make things easier.
From the Lenya point of view, I think it would look like
+---------------------------------------------+ | Complex Lenya CMS operations | +---------------------------------------------+ | Lenya CMS API | +---------------------------------------------+ | Cocoon repository API | +---------------------------------------------+ | Whatever repository (e.g., JCR) | +---------------------------------------------+
Do you think it would make sense to consider Lenya interests when designing this application-oriented API?
Most definately. It would solve me some issues with Doco as well.
Can you list the functionality you need? don't write code, just things you need, then we'll get a bunch of them together and we'll write the easiest interfaces that meet those needs.
Ok?
- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
