Sounds good! I think that EFS should cover exactly those aspects of file systems, which we need in our frameworks / generic algorithms - nothing more.
In terms of Monitoring, one thing to consider is that the monitor and the file system may actually be two separate providers. Consider the SSH remote file system that we have in RSE -- it doesn't provide monitoring capabilities. But some extender could go and write an add-on (using a separate channel to the remote) to provide a refresh monitor. I don't think that this use-case is extremely important, but I'd like to understand what's the benefit of moving the RefreshMonitor into EFS instead of keeping it separate. I agree that the Adapter pattern may be a nice way to provide access to add-ons like access to ACL's, ownership info, etc. That being said, and while you're looking at iFS ... I've been told that there exist file systems where the encoding of elements is specified by the file system. Others (HTTP, WebDAV) provide a Content Type right from the file system. I'm wondering if we'd want to support that in e4, or keep using a totally separate (non-integrated) mechanism for encodings and content types? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > I've been investigating the branched FS issue. iFS > (integrated file system > on i5/OS) is indeed very different from what I know already about > filesystems. > However it seems like a small change in EFS API will be > enough to support > such filesystems. > > Regards > -- > Szymon Brandys _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
