Hi, I've added the requirements for autosync to [1]. Although VLT does a good job of this once setup I don't use CLI for editing and manipulating. I use the IDE 100% with all its other tooling and just File Save. Setup with VLT is 2 commands and a 1 line config file edit, which could easily be converted into a IDE plugin.
Having thought about it, I think the reason vlt sync works well is that Sling is on the same box, monitoring the file system for changes, (I think thats right, there is no local process with vlt sync) and monitoring JCR for changes, which avoids lots of processing and http traffic. When I have used other forms of integration on large repositories, the volume http traffic and speed of response has nearly always made them unusable. What ever is used or reimplemented it must not rely on scanning a repository to know what has changed. It must relay on notification of some form so that Edit->Save->Refresh is never more than a few seconds, and doesn't impact the Sling server resource usage. Ideally notification should not rely on the IDE, since changes can be made without the IDE running, and routing it via the IDE is going to get really confusing with 3 or more potential sources of updates. (assuming code under version control) HTH Ian 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases On 31 May 2013 14:07, Ian Boston <[email protected]> wrote: > @Justin, will do. > > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its > internals). > > > On 31 May 2013 13:48, Ruben Reusser <[email protected]> wrote: > >> is the vlt sync now actually updating .content.xml files? I thought it >> can only sync regular files. >> >> Ruben >> >> >> On 5/30/2013 7:24 PM, Justin Edelson wrote: >> >>> Ian - please do add the autosync use case to the wiki page I created. >>> >>> >>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <[email protected]> wrote: >>> >>> Hi, >>>> +1 to that. After working on sling for many years doing a mixture of >>>> bundle >>>> and UI work, mainly using the FileSystemResolver bundle, I realise now >>>> if >>>> VLT had been available with sync mode (ie auto syncing the repo and the >>>> file system), we (the team I was working with at the time) would have >>>> made >>>> much more rapid progress. UI dev work needs file-save-refresh. The in >>>> browser editing UIs deliver this, as does VLT in sync mode, but >>>> unfortunately native eclipse based tooling is just too slow (on my >>>> machine, >>>> might be my machine). Using VLT since I joined Adobe, has been a joy, >>>> and I >>>> am very glad to know its being donated to the ASF. >>>> >>>> Had we had VLT then, we would have developed in a very different way, >>>> and >>>> might not have had half the problems we had with tooling and team >>>> structure. >>>> Ian >>>> >>>> >>>> On 31 May 2013 10:16, Justin Edelson <[email protected]> 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 <[email protected] >>>>> >>>>>> 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<https://cwiki.apache.org/SLING/slingclipse.html> >>>>>> [2]: >>>>>> >>>>> https://cwiki.apache.org/**confluence/display/SLING/** >>>> Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling> >>>> >>>>> >>>>>> >> >
