Hi, >It would be great if that would change for JR3 where every method (which >makes sense) is also exposed to an HTTP interface from the beginning. I >guess this would also make JR3 and the whole JCR idea much more >appealing to people outside of the Java world.
Yes, this is one of the goals for Jackrabbit 3. Remoting over HTTP is very important. The current plan is to support two kinds of remoting. * The first and most important is the remoting on the high-level Jackrabbit API (high level functionality, but the transient space is on the client). This includes functionality like versioning. This will be standardized. * The second kind of remoting might not be exposed at all, it is the MicroKernel remoting. It's used on a lower level, to remote low level MicroKernel API calls. The idea is to use it for virtual repositories and clustering. There is an implementation available already in the sandbox. Possibly (this is highly controversial) the high-level remoting will be just a superset of the low-level remoting, for example by defining additional semantics to the path and the data. >I'd gladly help, whenever I can, my java skills are just not really up >to what's needed here. We need to document the protocol, the semantics of the transferred data, and examples. No Java skills required :-) Regards, Thomas
