Hi *, just my cents.
First of all I am really happy to see this moving forward (thanks Robert for bring this up). About the usage of VLT I am not against it but I do not see any problem on having a further level of abstraction between the tooling and the "transport layer" (e.g. VLT) Regards Antonio On May 31, 2013, at 2:16 AM, 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. > > While it is true that VLT currently only works with DavEX servers, I > suspect it would not be hard to isolate the "Ex" bits and have a "WebDAV" > only driver which could be used on non-JCR applications for basic file > operations. > > My concern is that we end up building one more abstraction which is going > to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.). > > I know VLT has some baggage, but I'd just ask that people keep an open mind. > > 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. > > Regards, > Justin > > > On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <romb...@apache.org>wrote: > >> Hi, >> >> Following Antonio's kick-start of the Sling developer tooling [1] I've >> gathered some thoughts about the initial goals and implementation of our >> Sling IDE tooling. >> >> The document is at [2] so please have a look and let me know what your >> thoughts are. I intend to take a pass at the code next week and align it >> to the proposed structure, as a foundation for feature work. >> >> Robert >> >> [1]: https://cwiki.apache.org/SLING/slingclipse.html >> [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling >> >>
