Hi,
At first sight, I would say nay ;-)
Because, the RMI stuff is easy and simple to use and just works. Period.
Now, on the other hand the RMI stuff has some serious drawbacks:
* Performance (we never really built caching into it, which would
be hard anyways)
* Secondary communications channel besides HTTP
* Classloading issues
* .. and all the other problems related to RMI
Therefore, I agree with this proposal, all the more, that hopefully,
setting up a dav based communications channel supporting the complete
API (this would be a requirement for me for dropping RMI !) is as easy
and straightforward.
Regards
Felix
Jukka Zitting schrieb:
> Hi,
>
> So far I've just assumed that, since JCR 2.0 is backwards compatible
> with JCR 1.0, we'll have no trouble using the JCR-RMI layer on top of
> a JCR 2.0 repository even if the layer itself is still built against
> JCR 1.0.
>
> Unfortunately, now that I looked at this in more detail, my assumption
> turns out to be false. Since the JCR-RMI layer acts both as a JCR
> client and a server it's not possible for one end to use JCR 1.0 while
> the other uses JCR 2.0. Furthermore the remote interfaces and objects
> passed through RMI include javax.jcr.RepositoryException and a
> serializable javax.jcr.Value implementation, so even just splitting
> the JCR-RMI layer to separate client and server parts will not solve
> the problem.
>
> With enough work we could solve both of the above issues to make
> JCR-RMI work with all combinations of JCR 1.0 and 2.0 clients and
> servers. However I'm not convinced that it makes sense to spend all
> that effort when we now have the WebDAV-based remoting layer that's
> already pretty feature-rich.
>
> So I'm thinking of putting JCR-RMI on a maintenance track for old 1.x
> releases, and perhaps even dropping the RMI layer entirely from
> Jackrabbit 2.0.
>
> WDYT?
>
> BR,
>
> Jukka Zitting
>
