Brian Moseley wrote:
in any event, it seems pretty clear to me that the content store api (jsr 170 or custom) needs to be able to be used directly by applications as well as by the webdav adapter.
it also seems clear that if jsr 170 is sufficient as our own content store api, it should be our first choice, since other people are putting in work to implement content stores for it. best to spread effort among as many people as possible.
if jsr 170 turns out to not be good enough for whatever reason, then we come up with our own custom api, and perhaps we put a jsr 170 adapter on top of it that is a peer of the webdav adapter.
[snipping a bunch of discussion in which you come to the conclusion that i just worked out for myself above]
Looks like we're all in agreement then to use JSR 170. I just read and skimmed through the 200-odd page spec and it seems well thought out. The only part I didn't really like was the mandatory support for XPath searching, XML import and XML export. I believe such things should be optional, particularly when seemingly more useful features like access control and versioning are not mandatory (even for a level one implementation).
I've also had a look around the Jackrabbit code. The project states it supports JSR 170 levels one and two, and they have written an impressive number of classes (250+ in core alone). The file system is used as the default backend, with a contrib module for OJB and Hibernate based JDBC (Hypersonic and Mysql RDBMS platforms are used). Unfortunately it doesn't use IoC, though I did look at this in some detail and it wouldn't be overly difficult to add it in (if the Jackrabbit team were supportive). I'm also unclear on test coverage, as there's no Clover report at http://incubator.apache.org/jackrabbit/maven-reports.html. I also can't see where their JTA transaction integration is happening for the filesystem repository. Many key classes are missing JavaDocs and there's only a few pages on the web site explaining how to use it. Access control isn't done (ie you can't enforce ACLs) and Lucene is used for all search indexing (which is a problem in itself if you prefer a RDMBS backend for provisioning reasons or to avoid NFS locks in large installations). Checked exceptions are used, which is at odds with what our target community (Spring users) are used to and generally prefer. Finally, the project is only available via Subversion (no release binaries). I'm left with the overall impression that it's still pretty early-stage for Jackrabbit, although in the fullness of time it will become a quality RI.
Dependency on any early-stage project troubles me, mainly because of the impact it would have on our potential community. I can't picture a typical user who is wanting to evaluate Acegi WebDAV going to the trouble of setting up their SVN client (many still haven't needed to setup SVN yet), dowloading source via SVN, compiling, working out the XML configuration without much documentation, and then figuring out how to deploy it to a Spring IoC container. All that would be needed before they can start evaluating Acegi WebDAV, and if they want to customise any part of Jackrabbit they'll probably find it time-consuming (especially compared with a more native Spring-like implementation, where the community frequently and easily swaps out implementations of interfaces). Even if they did go through all of that, I wonder how many would deploy Acegi WebDAV into production when a fundamental dependency is at this level of maturity. I receive enough feedback about not have a 1.0.0 release number on Acegi Security (which is over a year old) - I could only imagine the comments if a key component was missing even 0.0.1 binary releases.
If we opted to leave Jackrabbit for the moment, I don't think building a Spring-based JSR 170 implementation that uses the Spring JDBC abstraction layer would be too difficult. If we used the standard Template pattern (as per Spring's Hibernate, JDBC etc support) we could ensure all JSR 170 implementations were accessed with the same transaction semantics as the rest of Spring. Importantly, a Spring-based JSR 170 implementation would avoid the time and classes that Jackrabbit has needed to invest for JDBC/Hibernate abstraction, transaction management, and configuration generally. I'd also suggest we limit the scope of our JSR 170 implementation to initially just support our WebDAV requirements. That will eliminate or significant reduce the need for supporting import, export and XPath. As long as we don't "market" it as a JSR 170 implementation, and allow complete JSR 170 implementations such as Jackrabbit to be used instead, I can't see any problem with this approach. We can always add those few additional JSR 170 features later, which would effectively make it compliant with JSR 170 level one and two, with the transaction, access control, versioning and locking options.
Irrespective of any WebDAV requirements, many Spring applications would benefit from JSR 170 services. I suspect any efforts on providing support/abstraction (template) classes for JSR 170 implementations would be warmly received, especially if backed with a Spring-centric JSR 170 implementation. This would probably give rise to further contributions and features from the Spring community.
I should mention http://forge.objectweb.org/projects/exoplatform/ also states it's a JSR 170 implementation, but its goals seem very broad (it's a portlet container). I didn't get time to evaluate Exo.
I am interested in your comments on Jackrabbit, Exo and/or implementing a basic, Spring-centric JSR 170 implementation ourselves.
Cheers 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
