JavaMail has a nice Folder.fetch(FetchProfile) method that lets the caller
share intentions on what kind of data access is going to happen.
Folder folder = store.getFolder("myNode");
Message[] messages = folder.getMessages(); // return light-weight references to
"node"s
FetchProfile fp = new FetchProfile();
fp.add(FetchProfile.Item.CONTENT_INFO);
Fp.add(FetchProfile.Item.ENVELOPE);
Folder.fetch(messages, fp); // pre-populate parts of each message with
FetchProfile, so only the remainder lazy-loads
This type of a "fetch" (pre-fetch) method is the perfect place to do a propfind
type of operation. A JCR equivalent would allow a caller to specify things like
depth, and nodetypes of interest, so that they can all be grabbed via a single
traversal of SPI, and then only the remainder of data accesses would cause
lazy-loading, like the heavyweight getProperty("jcr:data") calls, or whatever.
Dreaming on,
David
On 6/17/08 6:13 AM, "Jukka Zitting" <[EMAIL PROTECTED]> wrote:
Hi,
On Tue, Jun 17, 2008 at 3:57 PM, krisNog <[EMAIL PROTECTED]> wrote:
> What I really need to find out is what sort of latency there is when using
> RMI to make calls to the JCR API.
Most JCR-RMI calls are remote, so you'll have the overhead of a
network roundtrip per each method call.
There's been some discussion about avoiding so many network roundtrips
by pre-fetching or caching content on the client side, but so far such
improvements have only been implemented for some simple cases like
RangeIterator.next().
BR,
Jukka Zitting
