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