[platform-core-dev] IFile that corresponds to a logical view

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Forwarding this discussion from the
eclipse.platform newsgroup:

news://news.eclipse.org:119/dbnsfk$2a4$1@xxxxxxxxxxxxxxxx

Thomas Hallgren wrote:
> The Buckminster (Technology subproject)
uses an Eclipse extension point 
> to produce a dependency graph for
a component. One extension 
> implementation will use the the
Eclipse plugin manifest files as its 
> source, another uses Maven's project.xml,
a third uses the Buckminster 
> propriatary format. We forsee several
other implementations. Buckminster 
> maintain the graph in its workspace
meta-data. What I want to do is to 
> make this depencency graph available
as an IFile regardless of if it is 
> a concrete file (the Buckminster
proprietary format) or something that 
> is generated programmatically by
an extension.

Why do you wan to make it available
as an IFile?  Do you want this artifact to be treated as an IFile
in all cases, appearing in the Navigator inside some project, openable
with editors, etc? Do you want to attach markers or other metadata to it?
 I'm just trying to understand if you want this to be a "first
class" file in the workspace.

> 
> We could probably stipulate that
an extension contributor must make a 
> "primary source" resource
available and thus enable scenario 2). But if 
> we do, then that resource will
be eclipsed by the generated resource. 
> The contributors to the dependency
calculation are likely to be 
> resources in their own right and
we can't really violate that. So, even 
> if it is likely that there will
be at least one physical file, it still 
> feels like scenaro 1).
> 
> The more I think of it, isn't scenario
2) just as challenging in any 
> case? If some plugin does a getLocation().toFile()
and ends up with a 
> file that somehow contributes to
the logical content rather than no file 
> at all, then that might be just
as bad or even worse. Sure, you would be 
> able to open the file or check
if it exists but the content that you 
> read is incorrect and the existence
of that single resource doesn't 
> necessarily mean that the logical
resource is present. It might depend 
> on several files, on specific content,
etc. And, as with my example 
> above, the physical file might
be a resource in its own right.

My description of 2) was a bit scarce.
 I view this case as a logical domain-specific model that is backed
by a set of resources.  Most operations act directly on the domain
model and don't care at all that the logical model is stored in files.
 However, some operations require access to the physical file (such
as CVS operations).  In this case all that's needed is a transform
that can take a logical model element as input and produce (physical) IResource
objects as output.  In this case the IResource objects retain their
1-1 mapping with the file system.

> 
> I'd like to issue an enhancement
request but I'd like to discuss a bit 
> furhter what it would say. The
essence of it would (I think) be to make 
> the Eclipse plugins less dependent
on that a resource location maps to 
> the presence of a file/directory
in the local file system.

I think it ends up being an all or nothing
proposition.  As soon as an IResource is introduced that has no direct
mapping to the local file system, the whole platform needs to adhere to
that new abstraction, or things would simply stop working. 
> 
> The abstraction is there already.
The reason people break it is probably 
> lack of some functionality in IPath.
I know I break it because theres no 
> IPath.exists(), IPath.delete(),
IPath.isDirectory() or IPath.list(). 
> Perhaps they could be implemented
so that a check is made if the path 
> represents a resource, if it is,
then the information/action would be 
> obtained/carried out by that resoruce.
If not, then the local file 
> system would be consulted. Relative
paths would always be relative to 
> the workspace of course.

I think IPath isn't rich enough to express
it.  IPath only has a device, and an ordered array of String segments.
 I think you'd need something that's structured more like a URI (with
a scheme and a less structured portion that may be interpreted differently
depending on the scheme).  Also, IPath is currently heavily used to
represent things other than file system paths, such as abstract workspace
paths.  I.e., if IPath was overhauled to fit the bill of a complete
file system abstraction, it would end up looking very different and would
be difficult to do in a compatible way. In any case, this is an implementation
detail.

John
--


Thomas Hallgren wrote:
> John,
> Let me try and elaborate on what
it is I'm trying to do.
> 
> The Buckminster (Technology subproject)
uses an Eclipse extension point 
> to produce a dependency graph for
a component. One extension 
> implementation will use the the
Eclipse plugin manifest files as its 
> source, another uses Maven's project.xml,
a third uses the Buckminster 
> propriatary format. We forsee several
other implementations. Buckminster 
> maintain the graph in its workspace
meta-data. What I want to do is to 
> make this depencency graph available
as an IFile regardless of if it is 
> a concrete file (the Buckminster
proprietary format) or something that 
> is generated programmatically by
an extension.
> 
> We could probably stipulate that
an extension contributor must make a 
> "primary source" resource
available and thus enable scenario 2). But if 
> we do, then that resource will
be eclipsed by the generated resource. 
> The contributors to the dependency
calculation are likely to be 
> resources in their own right and
we can't really violate that. So, even 
> if it is likely that there will
be at least one physical file, it still 
> feels like scenaro 1).
> 
> The more I think of it, isn't scenario
2) just as challenging in any 
> case? If some plugin does a getLocation().toFile()
and ends up with a 
> file that somehow contributes to
the logical content rather than no file 
> at all, then that might be just
as bad or even worse. Sure, you would be 
> able to open the file or check
if it exists but the content that you 
> read is incorrect and the existence
of that single resource doesn't 
> necessarily mean that the logical
resource is present. It might depend 
> on several files, on specific content,
etc. And, as with my example 
> above, the physical file might
be a resource in its own right.
> 
> I'd like to issue an enhancement
request but I'd like to discuss a bit 
> furhter what it would say. The
essence of it would (I think) be to make 
> the Eclipse plugins less dependent
on that a resource location maps to 
> the presence of a file/directory
in the local file system.
> 
> The abstraction is there already.
The reason people break it is probably 
> lack of some functionality in IPath.
I know I break it because theres no 
> IPath.exists(), IPath.delete(),
IPath.isDirectory() or IPath.list(). 
> Perhaps they could be implemented
so that a check is made if the path 
> represents a resource, if it is,
then the information/action would be 
> obtained/carried out by that resoruce.
If not, then the local file 
> system would be consulted. Relative
paths would always be relative to 
> the workspace of course.
> 
> Regards,
> Thomas Hallgren
> 
> John Arthorne wrote:
> 
>> Thomas, do you mean:
>>
>> 1) That your "logical"
file is not in the file system at all, or
>> 2) That it doesn't map 1-1
with a single file, but the data is stored 
>> in files (either the logical
element spans multiple files or a single 
>> file contains multiple logical
elements).
>>
>> We are interested in exploring
these problems in the next Eclipse 
>> release.  We started to
make progress on 2) in the 3.1 release. Our 
>> approach has been to facilitate
the mapping of logical elements to 
>> physical files, rather than
turning IFile into a logical layer and 
>> hiding the physical layer entirely.
In many cases this is the only 
>> choice, since some tools, such
as repository plugins, typically have 
>> no choice but to deal directly
with the physical file level.  See for 
>> example the following bug:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723
>>
>> If you are interested in 1),
that is a much more challenging problem. 
>> Many plugins make the assumption
that IFile maps closely to a physical 
>> file, often by calling IFile.getLocation().toFile()
to obtain a 
>> java.io.File.  This class
of plugins (which includes most of the 
>> platform itself), would not
be able to handle an IFile that was not 
>> backed by a java.io.File.  However,
you are welcome to enter an 
>> enhancement request for this.
 It has frequently been discussed in the 
>> past but I was surprisely unable
to find anything in bugzilla on the 
>> subject.
>> -- 
>>
>> Thomas Hallgren wrote:
>>
>>> Hi,
>>> I'm considering the creation
of an IFile implementation that would 
>>> correspond to a logical
view (XML) of some computed data. The data 
>>> has no natural corresponding
file on disk.
>>>
>>> Besides providing the actual
data, what is required to do such an 
>>> implementation? How do
I register the implementation with the 
>>> workspace so that it can
be viewed, opened, etc. Is there an example 
>>> somewhere that I can look
at?
>>>
>>> Regards,
>>> Thomas Hallgren