[
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
|
BTW, I'm going through these in the order I recieved them so
please bear with me if this is already answered by now :).
- resource delta. As we discussed at the meeting, this is
definitely an area where we need investigation. Can we simply reuse the existing
resource delta mechanism, or do we need to involve the file system layer, or a
combination of both.
-
alias management. This is really a file system level issue, especially with the
problems we've had in the past with symbolic links. They need to be explicitly
modeled in the file system.
-
asynchronous APIs. As we discussed, there is a need for asynchronous APIs
as well as sync ones. The KDE IO system apparently does a good job at that.
We've also learned a lot from our experience at async-ness of device
debug.
-
alternative backing store for resources. As I mentioned in the proposal, the
mechanism for providing the resource to file mapping for a project should be
extensible. One of the extensions we'd need is one that replicates the existing
behavior to support bringing forward of existing projects. This could be used by
the RCP folk to keep things simple.
Cheers,
Doug.
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.
