Having filtering at the EFS level (which is analogous to have it at the Directory.Filter level discussed earlier in this thread) is a nice addition, although it is only as long as a method such as IFileStore. childStores(Filter, |int options, IProgressMonitor <http://developer.capeclear.com/7.5.1/help/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IProgressMonitor.html> monitor) is faster than the regular |IFileStore. childStores(|int options, IProgressMonitor <http://developer.capeclear.com/7.5.1/help/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IProgressMonitor.html> monitor).
This may be true for EFS implementations for remote file systems. For local files, if we really get the resource filtering right I agree that EFS-level filtering doesn't add much.
If I understand you correctly, the idea of IVisibleResource is really a linked resource, is that correct?
IVisibleResource may not be the best name. I'm looking at IVisibleResource to serve non-global, application-specific needs. Currently IResource = IFileStore + metadata. IVisibleResource is stripped of the underlying one-to-one relationship with an IFileStore. It expreses logical parent/child relationships and contains an optional reference to an IResource or IResourceProxy that backs it. It can represent linked resources or non-resource backed entities such as virtual folders/groups. If IVisibleResource drives IResource creation then it can represent and implement resource filtering. As Martin points out, reducing the scope of resource delta notifications is highly desirable and IVisibleResource might help manage that.
My thoughts are fairly unstructured but I am reacting to my perception that the IResource interface is already heavyweight because it bridges the file system, resource and applications layers, and a lot of new demands are being placed upon it.
--Terry
