Community
Participate
Working Groups
Right now when refreshes are done using the RSE EFS provider, there is a refresh that happens per folder. Things could be optimized (hopefully significantly) for large projects if IFileSystem.fetchFileTree() were to be implemented, as then the entire tree could be retrieved using only one command across the wire.
This would require new API at the Services Layer at least, likely also on the Subsystem Layer. Since as of today, all of RSE is built for just-in-time retrieval of directory information on the current level only. There's also a couple complications eg - How to deal with recursion (cyclic symbolic links or hard links) - How to deal with progress and cancellation in case the remote is slow (eg remote ClearCase MVFS can be very slow ... note that even the Eclipse Resources layer's refreshLocal() performs breadth-first-sear upto a certain max level only by default, in order to deal with file system slowness) In my opinion, the problem of EFS being slow needs to be solved on a differnet level ... In a huge database you also wouldn't want to know the status of all records. You'd rather send queries to the database for any information you'd want to retrieve, in a RESTful way. See also http://wiki.eclipse.org/E4/Resources/Semantic_File_System
