[eclipse-incubator-e4-dev] RE: [platform-core-dev] Straw man proposal

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: platform-core-dev-bounces@xxxxxxxxxxx 
> [mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> James Blackburn
> Sent: Friday, October 03, 2008 5:12 AM
> To: Eclipse Platform Core component developers list.
> Subject: Re: [platform-core-dev] Straw man proposal
> 
> Hi All,
> 
> On Fri, Oct 3, 2008 at 1:31 AM, Sergey Prigogin 
> <eclipse.sprigogin@xxxxxxxxx> wrote:
> > The requirement to have filters associated with folder resources is 
> > missing in the Strawman. It is important that the filters can be 
> > associated with folder resources at creation time to avoid reading 
> > files that are not intended to be a part of the project. This 
> > requirement is critical for scalability.
> 
> I think filters are a neat idea, but would only want them at 
> the Project layer not lower in the hierarchy.  From the 
> proposal the project layer appears to be completely decoupled 
> from the filesystem layer with everything in the project 
> layer effectively a linked resource (i.e. a mapping from 
> IResource to some EFS handle).  If a file is then filtered in 
> one project 'view' but not another I would say you still want 
> local history and the team providers to work (which it 
> wouldn't if it was filtered at the EFS level).

Yes, I believe we are talking about filtering at the Project layer. The
file system layer should be a true representation of what's on the file
system.
 
> Doug, the model seems pretty clear and neat!  You also make a 
> very good point about Markers in the hierarchy and whether 
> they might be associated at the filesystem or project -- and 
> I'm wondering whether this makes the case for a metadata layer.
> An example where you'd want a marker in different layers (at 
> project layer / fs layer):
> 1) breakpoint -- should probably be visible to all IResource  
> that map to the same efs file
> 2) build errors -- probably only applicable to the IResource 
> built in a particular context or project

Yes, I think a lot of the initial work will be deciding what
functionality properly belongs at the file system layer. The beauty of
the new architecture is that we have the facilities to make that
decision.

> If there was a metadata layer between EFS and Project, then 
> this could be the hold all for markers, local history, team 
> provider specific metadata, etc. for filesystem level 
> resources.  The Project layer would still hold the mapping 
> from IResource -> EFS, and would still contain API for 
> setting markers on a particular linked resource.
> Setting a marker at the project level would translate to a 
> call to the metadata layer with an additional attribute 
> referencing the linked resource in question.
> 
> In effect the metadata layer would provide filesystem 
> services-plus-plus. i.e. something you might get from an 
> advanced WinFS/BFS/ZFS/other-fs-with-attributes.  I would 
> think that this would reduce the complexity of having to 
> manage all the metadata and resource mappings in the project 
> layer, and resolve how and where the team provider (or other 
> low level plugin integrating at the efs layer) should store 
> its fs related metadata.
> 
> Does the above make sense or is there some fatal flaw in my logic?

Yes, I think this makes sense. It implies we need to associate metadata
at the file system layer as well. That could be very handy for a number
of different purposes.

Also, I am going to stop using the term linked resources. I'm not sure
they are necessary any more with this proposal. Any linking should be
modeled at the file system layer. And you can map a resource to any file
which is essentially solves the same problem as today's linked
resources.

Great points James.
Doug.

Doug.