Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [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?

From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Friday, October 17, 2008 1:40 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] [resources] EFS IFileTree

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.


Back to the top