[
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'd also like to hear the ECF story for remote. Scott L, are you able to
make the call?
Doug.
________________________________
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of
Schaefer, Doug
Sent: Friday, October 17, 2008 9:32 AM
To: E4 developer list
Subject: 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
