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

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] <> 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 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"?

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.


Back to the top