[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] Java7 / JSR203 and EFS
|
OK. You're wrong ;)
Actually the story I got was that it was to support files that weren't
necessarily in a physical file system - like a database or something.
I'm just saying let's close on a fast EFS first, deal with aliases,
notifications, etc, and then consider what a slow EFS would be like. I'm
not shutting that door forever, just for a couple of weeks so we can get
started.
Doug.
________________________________
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris
Recoskie
Sent: Friday, October 17, 2008 9:05 AM
To: E4 developer list
Subject: RE: [eclipse-incubator-e4-dev] [resources] Java7 /
JSR203 and EFS
> To that extent, let's start assuming that files are quick and
local.
I think I have to disagree with this. The primary reason EFS
came about (someone can correct me if I'm wrong), is to support remote
resources. If we're going to assume files are all quick and local, then
I think we eliminate probably 80% of the use cases that people are using
EFS for (the rest being for things like accessing files embedded in
archive files, etc.). If we're going to assume they're fast and local,
then why do we need EFS at all?
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
"Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
"Schaefer, Doug"
<Doug.Schaefer@xxxxxxxxxxxxx>
Sent by:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
10/16/2008 10:38 PM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
To
"E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
RE: [eclipse-incubator-e4-dev] [resources] Java7 / JSR203 and EFS
I could agree with that. I'm a bit worried about adding async
operations
to EFS. Async APIs are complicated to use (and I have tried
using the
Debug Services Framework which uses this paradigm to an
extreme). I
wouldn't want to force that on all users of EFS.
And I'm not convinced that features that assume the file system
is close
and local can work the same when the file system is slow and
remote. I
have to believe that workflows and designs would be different.
To that extent, let's start assuming that files are quick and
local. And
let's investigate how we could leverage ECF to support remote
file
systems. If that doesn't meet our needs, we can always add async
later.
Doug.
> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Scott Lewis
> Sent: Thursday, October 16, 2008 1:42 PM
> To: E4 developer list
> Subject: Re: [eclipse-incubator-e4-dev] [resources] Java7 /
> JSR203 and EFS
>
> Thanks for the JSR203 info.
>
> FWIW, we (ECF) are committed to building nio/nio2-based
> providers for the ECF filetransfer API. I think it would be
> a mistake to define yet another (i.e. EFS-async) API in
> preference to using/extending/enhancing/integrating what ECF
> already has (e.g.
> particularly WRT progress reporting and cancellation).
>
> Scott
>
>
> Oberhuber, Martin wrote:
> > Hi all,
> >
> > I investigated a little bit more about JSR203 (nio2 /
filesystem
> > access), and here's some data points:
> >
> > * The most current data about JSR203 is from the binary
early
> > access download [1] <
http://download.java.net/jdk7/jsr203/>.
> > Install this on your system, read the
> > sources, try it out or generate Javadocs from it --
> the original
> > JSR203 document as from the JCP is outdated, e.g. the
package
> > name changed from java.nio.filesystem to
java.nio.file.
> > The full Jdk7 EA downloads also don't have nio2 in it
yet!
> > * A 1-hour YouTube video (from a techtalk at Google, May
1) is
> > available here [2]
> > <
http://dlinsin.blogspot.com/2008/07/jsr-203-more-new-io.html>
> > * A nice list of additional pointers is here [3]
> > <http://tech.puredanger.com/java7/#jsr203>, with a
(slightly
> > outdated)
> > HTML overview here [4]
> >
> <http://today.java.net/pub/a/today/2008/07/03/jsr-203-new-file
> -apis.html>.
> >
> > In terms of its relation to EFS, I think the more
> interesting bits are
> >
> > * *Monitoring API*, which Szymon has mentioned already
> > * *File Attribute Views*, which allow requesting a set
of file
> > attributes
> > with optimized operations. EFS only has
> IFileStore#fetchInfo(),
> > which is OK right now (since all info to be fetched
> is available by
> > means of a stat() call), but is less than optimal if
> we want to
> > fetch
> > other kinds of attribute information... since we
wouldn't want
> > to burden
> > clients which only need the modtime, for instance,
with a full
> > fetchInfo()
> > that fetches information not needed.
> > * *Creating Symbolic Links*
> > * *Allowing URI *for converting from/to File/Path --
> nice for EFS :-)
> > * *DirectoryStream* for async directory retrieval -- all
other
> > operations are
> > synchronous, so I'm questioning whether we really
> need full async
> > support in EFS for reading attributes etc. I haven't
yet fully
> > understood
> > the AsynchronousFilechannel class.
> > * *Support for Locking* files against other programs
> > * *Path.isSameFile(Path)* basically a fast equals()
without
> > getCanonicalPath()
> > I find this a very interesting feature for Alias
Management,
> > depending on the
> > algorithms to be used... just imagine being able to
use a very
> > fast UNIX
> > inode number for checking fiel equality, instead of
doing
> > getCanonicalPath().
> > * *Provider Interface, *so if we're writing an EFS
> implementation
> > based on
> > JSR 203, adopters can implement a custom JSR203
> filesystem beneath.
> >
> > EFS is better than JSR203 when it comes to *progress
reporting and
> > cancellation* --
> > all the JSR203 operations seem atomic (readAttributes(),
copyTo(),
> > moveTo()) whereas
> > EFS allows IProgressMonitor for these operations.
> >
> > Attached is a little test program I wrote (under EPL), if
you are
> > interested.
> > Of course, this needs the JSR203 ea from [1] to run :-) The
> output of
> > my program is this:
> >
> > Same!
> > p2URI: file:///C:/PROGRA~1/ <file:///C:/PROGRA%7E1/>
> > realpath: C:\Program Files
> > canonical: C:\Program Files
> > compareTo: 0
> > attrs: {owner=BUILTIN\Administrators,
> >
>
acl=[BUILTIN\Users:READ_ACL/EXECUTE/READ_NAMED_ATTRS/READ_ATTRIBUTES/S
> > YNCHRONIZE/READ_DATA:ALLOW,
> >
>
BUILTIN\Users:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW, ...]}
> >
> > [1] http://download.java.net/jdk7/jsr203/
> > [2]
http://dlinsin.blogspot.com/2008/07/jsr-203-more-new-io.html
> > [3] http://tech.puredanger.com/java7/#jsr203
> > [4]
> >
>
http://today.java.net/pub/a/today/2008/07/03/jsr-203-new-file-apis.htm
> > l
> >
> > Cheers,
> > --
> > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind
River*
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> >
>
----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> >
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
