jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: JCR over RMI
Date Sun, 21 Nov 2004 16:00:05 GMT
hi jukka,

On Sun, 21 Nov 2004 12:25:29 +0200, Jukka Zitting <jukka@zitting.name> wrote:
> 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
> http://zitting.name/jukka/2004/11/jcr-rmi-0.1.patch.

great, that sounds very good. i'll certainly have a look at it.
i think it would be great if we could add your implementation 
as a separate target to jackrabbit.

as david already mentioned, i had done exactly the same thing
(a stupid transparent rmi layer on top of the jcr api) a while ago
but had to give up because the api was still too volatile and keeping 
up with the latest api release was too time consuming. 

btw: in case you're interested, you can find the old implementation 
in the slide cvs' attic: 
http://cvs.apache.org/viewcvs.cgi/jakarta-slide/proposals/jcrri/src/org/apache/slide/jcr/remote/?hideattic=0

> 
> > 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. 

Ticket had been renamed to Session sometime after the public review
to better reflect its semantics. revert() became refresh(). the semantics 
of the methods (save(), refresh()) didn't change though.

> I suppose the updated
> JCR API docs will not be available before the final draft. (This is my
> point about API stability.)

i know that this is a problem, but our hands are unfortunately tied by 
the jcp rules. i hope we'll find a way to solve this as it doesn't help 
attract potential contributers.

cheers
stefan

> 
> 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
> jukka@zitting.name
>

Mime
View raw message