Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of david.nuescheler@gmail.com
 designates 64.233.170.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=YXY0hZG22rAM9EsMCAhRIWAM4TMIRS2BFlCorNKpY2BQLJy0wFZT9eL0BE356hzWKlrfcnSl5qlyJz4Jn/DOL9IVfmWAEnul5qgkPlowgBGMDTjaTthrVzYsemNHYsrmMLbDxWoVE/mOMvjKWn7/JWKkUUUume5A4NkrkNyZzTo=
Message-ID: <eb7e21904112002495a0d9602@mail.gmail.com>
Date: Sat, 20 Nov 2004 11:49:48 +0100
From: David Nuescheler <david.nuescheler@gmail.com>
Reply-To: david.nuescheler@day.com
To: jackrabbit-dev@incubator.apache.org
Subject: Re: JCR over RMI
In-Reply-To: <419E7F49.9030109@zitting.name>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <419E7F49.9030109@zitting.name>

hi jukka,

> In the spirit of "Do the simplest thing that could possibly work" and
> "Release early", I've made my simple and very incomplete "JCR over RMI"
> implementation available at:
> 
>    http://zitting.name/jukka/2004/11/jcr-rmi-0.1-src.zip
> 
> The main goal of jcr-rmi was to get to know the JCR API. Another goal
> was to implement the "Model 3: The Repository Server" deployment model
> as easily as possible (DTSTTCPW). I wanted to create a JCR server with
> no external dependencies (databases, j2ee, ...). As I found no signs of
> a similar project, I decided to write something myself.
cool... that's the spitit ;) .

> The jcr-rmi project provides a simple RMI extension for the JCR API.
> Through RMI, one or more clients can access a content repository that is
> located on a remote server. With RMI-CORBA and RMI-SOAP mappings it
> would (theoretically) be possible to provide language-independed access
> to the content repository.
excellent. we are currently working on a webdav (+ friends) mapping, but
the rmi layer is certainly great value.

> The project is currently packaged in fi.yukatan.* based on my company
> (just starting, thus evaluating new technologies), and uses standard
> "All rights reserved" notices. If there's interest, I'd be happy to
> contribute the code to Jackrabbit, although it actually only depends on
> the JCR API (version 0.15) and not on the Jackrabbit implementation.
that sounds great, thanks. i am very interested, therefore i will certainly 
have a more detailed look... 
at a much earlier stage, stefan already built an rmi layer but
we never got around doing it for a recent jsr-170 api.
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.

> The project consists of three packages:
> 
> fi.yukatan.jcr.remote
>    An RMI mapping of a subset of the JCR API
> 
> fi.yukatan.jcr.client
>    A JCR API implementation, that maps all method invocations to
>    corresponding remote methods.
> 
> fi.yukatan.jcr.server
>    A remote JCR server, that maps all method invocations to the
>    corresponding methods of a local JCR implementation.
> 
> The implementation is very naive and incomplete. Almost all methods are
> directly mapped to remote equivalents with little caching or bundling of
> remote data. In addition, only a small subset of the JCR methods have
> actually been mapped over RMI. Most of the client methods just throw
> UnsupportedOperationExceptions. The implementation is barely able to run
> the "First Steps" examples over RMI.
> 
> Once you have a local Repository instance, you can publish it using the
> ServerRepository wrapper:
> 
>      Repository repository = ...;
>      ServerRepository server = new ServerRepository(repository);
>      server.bind("//hostname/servicename");
> 
> See the RMI documentation for the required options and other setup
> needed for starting the service.
> 
> The remote service can then be accessed by a client simply with:
> 
>      Repository remote = new ClientRepository("//hostname/servicename");
> 
> The client depends only on the jcr and jcr-rmi jars.
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?)

> PS. Thank you all for the work on JCR and Jackrabbit! I'll be eagerly
> waiting for the final draft and release of the API, and the related
> Jackrabbit releases. :-)
> PPS. Should I stall my work on jcr-rmi until the API stabilizes
> properly? As was already mentioned, it seems that there is growing
> activity around the main Jackrabbit implementation. I hope that this is
> not too distracting for the main project.
personally, i think that the api has stabilized quite nicely by 
now. however, there are always going to be changes up to the 
final approval ballot and it is a very subjective decision with how 
much change you are willing to cope with ;)

regards,
david
----------------------------------------------------------------------
standardize your content-repository !
                               http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


mailto:david.nuescheler@day.com
http://www.day.com

David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland

T  41 61 226 98 98
F  41 61 226 98 97