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.
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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.
John
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
