Re: [platform-core-dev] Straw man proposal

["James Blackburn" <jamesblackburn@xxxxxxxxx>]

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).

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

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?

Cheers,

James

>
> -sergey
>
> On Thu, Oct 2, 2008 at 5:18 PM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx>
> wrote:
>>
>> Hey gang,
>>
>> To feed the discussion for tomorrow's resource meeting, I have put
>> together a straw man proposal for the e4 resource system architecture. I'm
>> sure it has a lot of holes and I'm hoping you'll help me fill them. I could
>> also be totally on the wrong track and maybe there's better answers we can
>> put on the table. But let's discuss.
>>
>> The proposal is here: http://wiki.eclipse.org/E4/Resources/Strawman
>>
>> Also at tomorrow's meeting we should discuss if we want to continue our
>> discussions on the platform-core-dev list, or move them to the e4-dev list.
>> My opinion is changing on this. I'd like to get concensus from the team on
>> how we want to do this.
>>
>> Cheers,
>> Doug.
>> _______________________________________________
>> platform-core-dev mailing list
>> platform-core-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>>
>
>
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
>
>