re "beef up the FS layer" -- I'd like to at least understand whether we can do a better job of modeling the capabilities of particular filesystems, as we currently do for case sensitivity. Obviously, I'm thinking about some of the more unusual features of the filesystems on System z and i, but I could also imagine trying to model model things like the potential for high latencies (as a way to decide whether or not to use async APIs), for example.
McQ.
From: "Oberhuber, Martin" <[EMAIL PROTECTED]>
To: "E4 developer list" <[email protected]>
Date: 07/10/2008 13:17
Subject: [eclipse-incubator-e4-dev] [resources] File system layer
requirements
Hi all,
I had some thoughts about the Strawman proposal, and the file system
layer in particular.
We have a requirement to extend usability of Eclipse tools beyond the
Workspace. Bugs are open which request, for instance, capabilities to
Search files and folders outside the workspace, open editors, add
markers, ... apparently, we'll want to do all that on the Filesystem
layer.
Given that, the Filesystem layer must be stateless (we cannot
maintain state in memory for a tree that can become arbitrarily
large, since that wouldn't scale). The Filesystem layer must take its
information from the filesystem alone, and nowhere else. Which seems
to tie in nicely with ideas of having the FS layer RESTful.
If the Filesystem layer is stateless, we cannot push down any
resource deltas, since these require state ("before" vs "after" the
change). The Resources (Project) layer would remain the one which
holds state just as it does today.
I like the idea of pushing down metadata such that (a) markers can
live outside the workspace on FS objects, and (b) file system
capabilities for storing metadata such as Encoding or content type
can be leveraged. Perhaps that metadata layer could even be totally
separate from both FS Layer and Resource layer, linked with them
through URI as the identifier, and some resource delta callbacks for
lifecycle management. The other option is to leave it with the
Resource layer, but make it lazy (see below).
This brings up the question, where we really need to beef up the FS
layer? I actually don't see much need for this, except for
(a) adding asynchronous support if needed ... though that brings up
other questions (see my other E-Mail), and
(b) adding an IFileStore#getCanonicalPath() API which we clearly need
for Alias resolution.
I think that we can not have full Alias Management on the FS Layer,
because:
1.) one requirement of Alias management is that given some file X,
you need to know "who else links to X?".
2.) Now that kind of "reverse lookup" of symbolic links is not
supported by file systems, so it must be solved in code.
3.) That, again, requires that clients have "expressed interest" in
X before, which is adding state to the file system, which we cannot
have on the FS layer.
I think that we need to keep Alias Management on the Resource/Project
layer, supported by the getCanonicalPath() API on the FS layer. In
order to still support Alias Management for items outside the
workspace (that have been looked at before), we'll probably want some
"lazy addition to Workspace" paradigm which adds files and folders to
the workspace as they are being visited (and probably removes them
again after some time with an LRU paradigm).
Now that being said, it looks for me as if the necessary enhancements on
the FS layer could even be done in the Eclipse 3.5 Stream (adding
IFileStore#getCanonicalPath()).
Or am I missing any requirements on the FS Layer?
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
