[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-incubator-e4-dev] Straw man proposal
|
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.
-
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
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.
