jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <ju...@zitting.name>
Subject Re: JCR over RMI
Date Sun, 21 Nov 2004 10:25:29 GMT
Hi all,

David Nuescheler:
> since this also is a seperable contribution we would probably need 
> a CLA on file from you once the jackrabbit devs choose to accept
> your contribution.

OK, the CLA is no problem. If you want the code, I'd be happy to send 
the CLA.

Based on Sylvain's proposal, I've now moved the current code into 
packages org.apache.jackrabbit.rmi, org.apache.jackrabbit.rmi.client, 
and org.apache.jackrabbit.rmi.server, and changed the copyright notices 
to the Apache standard. The new version is available as a patch file, 
that should apply cleanly to the current codebase (all changes are new 
.java files in o.a.j.rmi.*, except the rmic addition to maven.xml). The 
patch file can be downloaded at 

> just out of curiosity, did you ever think about running the entire
> transient space on the client? (which is no longer straight forward
> rmi, but could network traffic could be drastically reduced?)

That's the long term plan, so far I've just wanted to keep the mapping 
as simple as possible.

I'm also a bit confused about the current status of the methods that 
control the transient state. The JSR 170 public review specifies (at 
least) the Ticket.save(), Ticket.revert(), and Node.save(boolean) 
methods for this purpose. However the current API (0.15) used by 
Jackrabbit seems to use methods Sesssion.save() and 
Session.refresh(boolean) for this purpose. I think I can see the 
reasoning behind this change, but I wouldn't want to try guessing the 
semantics based on the Jackrabbit implementation. I suppose the updated 
JCR API docs will not be available before the final draft. (This is my 
point about API stability.)

I'd also like to do some bundling of node information. For example, the 
standard node type properties could be sent to the client already when a 
node is requested, not in a separate getProperty() request. If I assume 
correctly, the new Session.refresh(boolean) method would greatly 
simplify the semantics of such cached data.

Best regards,

Jukka Zitting

View raw message