[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-core-dev] RE: [eclipse-incubator-e4-dev] Straw manproposal
|
Man I hate out look for adding comments to mails like this
:(
Anyway, yes, Sergey, you are correct. The delta mechanism is
at the Project layer. Deltas would only be generated for resources as filtered
by the projects, not for all files.
Doug.
On Fri, Oct 3, 2008 at 7:55 AM, Oberhuber, Martin
<Martin.Oberhuber@xxxxxxxxxxxxx>
wrote:
Hi
all,
just few
thoughts for discussion based on the Strawman proposal:
-
Where is
the resource delta / notification mechanism going to live?
If
the filesystem (EFS) layer is to support direct copy/move operations,
should these lead to resource deltas? If yes, then the filesystem
layer needs resource delta / notification / refresh mechanisms, which I'm
not sure is a good idea since I like the current design of filesystem ==
stateless and resources ==
stateful.
Filters have to live in the same layer or below deltas. Otherwise Eclipse
will continue to choke on very large directory trees as it does today.
-
-
Where is
alias management (symlinks) going to live?
Right now it's at
the resource layer, is it going to be pushed down to the filesystem
layer?
-
What
about asynchronous APIs?
EFS is synchronous in nature, do we
want to beef it up to support asynchronous, or forget about
it?
-
What
about alternative backing storage for Resources?
Right now, the
only coupling between EFS and Resource is the URI. If this is to change,
it won't be possible any more to have an IResource implementation that is
not backed by an actual file system. Is this desirable? What do RCP people
say to that?
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff,
Wind River
Target Management
Project Lead, DSDP PMC Member
-sergey
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.
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