[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] File systemlayer requirements
|
Good points.
In fact, it looks like up to now EFS has been more or less the "least
common denominator"
of all file systems that Eclipse can run on. It looks like this needs to
change, in order to
adapt to the capabilities that specific file systems
expose.
FYI, I just noticed that JSR 203 ("NIO2") [1] looks
like it is going to be added to Java 7, and is going
to include some new File system APIs -- for bulk retrieval of attributes,
asynchronous access, and
change notifications. We might want to prepare EFS2 for those additional
capabilities.
An important question for me, at this point, is how much of these
extensions is necessary NOW
in the context of E4, and what could probably be
deferred.
Addition of asynchronous APIs seems to be a rock big
enough to not allow it in a
minor release, since it tends to bubble up all across the system as I have
mentioned
before. I'd like to see somebody claim ownership of that
particular area. To say it
bluntly, I don't think that this owner is going to be myself, since I envision the
Wind River usage of Eclipse mostly remain on the local file system ("IDE"
kind
of use) in the forseeable future, so our interest in asynchronous APIs is likely
not as
high as for other contributors.
We'll need to look at other potential features 1 by 1. The Eclipse
strategy of not adding features without an existing client or use
case
has proven well so far, or would anyone argue in favor of adding
API
now for E4, just because "we might need it
eventually"?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
re "beef up the FS layer" -- I'd like to at least understand whether we can
do a better job of modeling the capabilities of particular filesystems, as we
currently do for case sensitivity. Obviously, I'm thinking about some of the
more unusual features of the filesystems on System z and i, but I could also
imagine trying to model model things like the potential for high latencies (as
a way to decide whether or not to use async APIs), for
example.
