Here my 2 cents about Sling Tooling & vault, IMHO vault is pure JCR Tooling. And even if some people do not like the fact, but the resourcetree is different from the jcr tree. So in consequence this additional abstraction of the Resource API is there (even without additional resource resolvers, since Sling Servlets are not present in the JCR Tree as well). Due to that I think vault AS IS is not the right choice since this would hide everything happening on the resourcetree layer. Having a complete view on the Resourcetree at least in the /apps and /libs section would be something I really would appreciate.
Best regards Dominik On Fri, May 31, 2013 at 2:04 PM, Robert Munteanu <romb...@apache.org> wrote: > Hi Justin, > > (and this will address Ian's comments as well ) > > On Thu, 2013-05-30 at 20:16 -0400, Justin Edelson wrote: > > Hi, > > I would strongly suggest that this effort be based on VLT. As mentioned > on > > the wiki page, we're in the process of moving that to ASF and I think > once > > the code is available, it will be clear that it provides a good low-level > > interface for this type of UI. > > I have not yet reviewed how embeddable VLT is, but it's hard to believe > that it will be a perfect match for both the IntelliJ and Eclipse plugin > APIs. As I noted, you should not directly read from/write to the > filesystem in Eclipse ( and I expect IntelliJ to have similar > requirements ) for both user experience ( stale workspace resources ) > and performance ( forced refresh of resources from disk ) reasons. > > As such, we will need a wrapper over VLT anyway to make this API > IDE-friendly. So there's no large effort to have transport API layer. > > Also, echoing Antonio's and Carsten's comments, I think that while VLT > is a powerful and mature tool, it does not work on top of the resource > API that we have in sling. > > We already have a MongoDB resource provider in contrib [1] and a GSoC > project accepted which will create an Apache Cassandra resource provider > [2]. A resource-based transport implementation will help us make those > implementations first-class citizens. > > (snip...) > > > > Separately, I'm going to start a child page of this wiki page to gather > use > > cases. There are some functional areas listed on the main page, but I > think > > we should try to capture individual use cases. > > > +1 > > Robert > > > [1]: > http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb/ > > [2]: http://sling.markmail.org/thread/ugghepk5hod55fy5 > >
