Community
Participate
Working Groups
Build Identifier: I have created an implementation of HTTP EFS. It supports both http and https. Index pages are treated as dir listings and Apache and Lighttpd default index pages are supported up to now. UI is implemented (File -> New -> File -> Link to file in file system). I wonder if you guys are interested and where can it go (maybe org.eclipse.ui.examples.filesystem) ? I saw that the Cape Clear's HTTP EFS (from EFS wiki) does not exist anymore. Reproducible: Always
Created attachment 162655 [details] org.eclipse.core.filesystem.http
Ed, does this overlap your work in the semantic file system?
(In reply to comment #2) > Ed, does this overlap your work in the semantic file system? John, not really. The proposal goes into a different but very interesting direction. By parsing index pages as dir listings for IFileStore.childInfos(), it allows browsing of rather static web sites as if they were remote file systems. SFS is designed to work with rather "dynamic" web sites where there is huge/indefinite/unlimited amount of resources underneath a URL prefix (just concider REST URLs of popular social networking websites with millions of users). With SFS, the resources are picked up selectively (by Eclipse user or by client-side logic) so that IFileStore.childInfos() returns the local list. There are differences but I also see some synergy. The proposed HTTP EFS implementation does caching of HTTP file stores as performance optimization. But there is currently no API to reload the cache. It is ok as long as the static websites have really static or rarely changing structure. SFS also caches SFS file stores for the same reason. But SFS also provides APIs to control/refresh the cache. The APIs are provided on two levels: on EFS level and on IResource level. The intention of the SFS Cache Control APIs is to standardize them and make them reusable. The APIs can be refactored and detached from SFS so that other EFS implementations can implement them.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
