[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
