[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] e4 Resources Kickoff Meeting
|
The Mac file system is an interesting case in point: They have both OS level aliasing via links (hard and soft) as well as "aliases" at the level of the finder. My experience has been that they do a relatively poor job of dealing with the implied context. Often aliases are ignored, even by UI application, but those can be fooled into using links. Even when using links though, the reporting of things like absolute paths seem to be pretty inconsistent.
Aliasing is a very difficult problem.
Random thought: A Mac "alias" file is itself a resource, which could have markers written against it (even now). Could we have a distinction between the actual resource and a collection aliases for it, and then add markers to the aliases.
McQ.
"Oberhuber, Martin" ---17/09/2008 12:32:04---Hi all, I think the important point is to acknowledge that aliasing
![]()
From: | ![]()
"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> |
![]()
To: | ![]()
"Eclipse Platform Core component developers list." <platform-core-dev@xxxxxxxxxxx> |
![]()
Date: | ![]()
17/09/2008 12:32 |
![]()
Subject: | ![]()
RE: [platform-core-dev] e4 Resources Kickoff Meeting |
Hi all,
I think the important point is to acknowledge that aliasing
generates ambiguity: should the aliased file be treated with
identical context or different context? I think that users
should be able to choose the semantics.
In E4, choosing the semantics should be explicit, and
simple for the user. In fact, the whole topic of Aliasing
seems like a theme and big rock for E4 Resources by itself.
In Eclipse 3.x, you can choose semantics as follows:
(a) Create a symbolic link on the file system in order
to create the alias --> file is treated with different
context (different markers, different parsing, different
project, ...)
(b) Create a linked resource for in order to create the
alias --> If the linked resource points into an
existing project, that project's context will be
the "native context" of the file and used regardless
of wherever the file is linked into.
I'm not sure about the context when two linked resources
point to the same file (outside the workspace) -- it's
ambiguous.
Both options (a) and (b) can make sense in some scenarios,
there is no "better" or "worse" one.
Part of the E4 resources effort, IMHO, should be resolving
such ambiguities.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev

