[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] [resources] File systemlayer requirements
|
Hi Martin,
Oberhuber, Martin wrote:
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]
<http://tech.puredanger.com/java7/#jsr203> 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.
Although this looks (to me) like an interesting/useful addition to
JSR-51 (i.e. the nio stuff in JRE 1.4), it looks like it might be a
little while before it's widespread. Further...I'm not sure of the E4
project's target JRE/OSGi runtime version...has there been any
discussion about such constraints? But, in any event it does look
useful as an addition to the new io stuff (at least partially because I
think the nio is so hard to use).
Just for everyone's information...we (ECF) have been/are starting work
on an ECF filetransfer provider based httpcore (i.e. httpclient 4.0)
...which uses the nio APIs.
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.
ECF is/has been/will continue to be focused on delivering both async and
sync APIs, and does expect to be a significant contributor to E4. At
least that's what we've got in our plan [1]. We are able to offer
contributions (of both existing and new work)...but only if they will be
accepted rather than reproduced and/or reimplemented. And although I
would like to offer ownership, and believe we have plenty to offer, I
don't know how much such a commitment would entail...as we have our own
project commitments to satisfy, and relatively few resources next to E4,
Platform, or other projects.
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"?
[1] http://tech.puredanger.com/java7/#jsr203
I'm of the opinion that async APIs are needed already (not only
eventually)...otherwise what's driving the 'be more asynchronous' item
for E4? (I don't really know the history of that architectural
requirement for E4). Plus Mike's very simple local vs. distributed
workspace use case(s). But I do agree that a clear understanding of use
cases for asynchrony is desirable.
Scott
[1] http://www.eclipse.org/projects/project-plan.php?projectid=rt.ecf
