[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[List Home]
|
RE: [eclipse-incubator-e4-dev] [resources] EFS IFileTree
|
- From: "Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
- Date: Fri, 17 Oct 2008 10:54:17 -0700
- Delivered-to: eclipse-incubator-e4-dev@eclipse.org
- Thread-index: Ackwf1dy17PjPukqS72m6JVa0CCoOwAAd16A
- Thread-topic: [eclipse-incubator-e4-dev] [resources] EFS IFileTree
That's true. I noticed it when playing with EFS last year. I
didn't implement it and things seemed to be fine. Are the clients that use this
API right now? If so, I assume the check for null and use the regular slower
way?
Cheers,
Doug.
I forgot to mention this during
the meeting, so I just wanted to mention a little know EFS interface called
IFileTree. The idea of this interface was to allow for batched interaction
with an entire file sub-tree. This prevents the large number of round-trips
needed when a client needs to walk over an entire subtree of a slow/remote
file system. It allows you to get a snapshot of an entire remote tree state in
a single round-trip. In some experiments we did back in the day, this
dramatically sped up certain operations like refreshLocal over a high latency
remote tree. I mention it only because it's probably an under-exploited
concept that could perhaps be expanded upon to improve performance in remote
resource scenarios. I could imagine expanding the idea to allow a client to
queue up a whole batch of file changes, that could be fired off in a single
round-trip to the remote system for processing.
John