Oliver Hutchison wrote:
I hope you guys don't mind me coming in a bit late on this discussion -No worries Ollie. I'm just keeping the project low-profile until we're 100% clear on our direction and have an initial release to offer the community. My strong preference is to integrate with the Jackrabbit project as much as possible, but it will depend on how aligned our goals are on pluggable interfaces and IoC configuration. We're in discussions on the Jackrabbit list at present.
I've only just discovered this project.
I hadn't really considered the scope in any depth, but it definitely included wrapping checked exceptions, convenience template/callback methods, and integration with some sort of FactoryBean to front JSR 170 implementations like Jackrabbit. I hadn't looked into it in any further detail, but certainly welcome your ideas (and involvement if you wish).Ben, what exactly do you have in mind when you say "JSR 170 abstraction layer" would it be something similar to Spring's existing template mechanisms or are you thinking of adapting the JCR classes to something more "friendly"? "friendly" for my purposes would mean no checked exceptions, providing getters for the JCR internal properties ("jcr:primaryType" "jcr:mixinTypes" etc...), automatically giving all new nodes the "referenceable" and "versionable" mixin, and a simplified versioning system where changes to workspaces can only be transferred in/out of a "master" workspace rather that between any 2 workspaces (I'm not sure I've got my head around the JCR versioning stuff...). I guess, in essence, what I'd like to see is a much simpler API.
With regards to the Jackrabbit WebDAV implementation; I get theIMHO remote applications needing JSR 170 level services should be using the official JSR 170 API interface and accessing server-side implementations using an appropriate, cross-platform binary or XML protocol (SOAP, HttpInvoker, RMI, Hessian). That would support various client types without the effort of developing a WebDAV-based interface, although you have to admire the overlap and thus novelty of the idea. WebDAV is of course a perfect protocol for providing general-purpose access to the JSR 170 repository (ie versioning, locking, content management). The example you noted is exactly what my requirements are for starting this project, and nothing more.
impression from reading the mapping document that Day have produced that
they are essentially trying to map the WebDAV API directly onto the JCR
API. Is this really that useful? If I was going to provide a low level
remote API onto JCR I doubt I'd expose it using WebDAV. IMO what is
presented through a WebDAV interface should be fairly application
specific. Does the designer Joe Blogs, when he connects to the server
using Dreamweaver, really need to know what "jcr:primaryType" or
"jcr:uuid" etc are supposed to mean? Ideally a WebDAV implemetation over
JCR would give you some way to "decorate" away all JCR internals.
Perhaps that's something that this project could offer...
In one way I feel starting a fresh implementation of JSR 170 and WebDAV is the best way of making it as "pure IoC" as possible, but equally I recognise the significant effort involved, the good work done over at Jackrabbit, and the desirability of not unnecessarily fragmenting the JSR 170 user community. I just hope our goals align sufficiently so that we can all work together and generate a single, quality implementation. My own goal is simply to have a quality, pluggable WebDAV server that is Spring-friendly.
Best regards Ben
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Acegiwebdav-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegiwebdav-developer
