Skip to main content

[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"?
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Wilson
Sent: Tuesday, October 07, 2008 8:31 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] [resources] File systemlayer requirements

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.

Back to the top