On 10 Jul 2014, at 15:36, Angela Schreiber <[email protected]> wrote:
> hi lukas > > what you looked as is just initial draft.... nothing that you can > use with your jackalope setup... it's still not ready and far away > from being a 'native' implementation of the spi server side part > that would allow you to remote the jcr calls without having yet > another jcr implementation on the server side. > > this latter setup should be feasible with oak instead of jackrabbit > by replacing the jackrabbit-core repository factory by one that > contains oak-jcr inside. > > in other words: you would need to change jcr-server setup such that > it uses the corresponding factory and configuring > the repository-access-servlet accordingly. > > i don't recall the very details by heart but you may want to > look at the corresponding code in jackrabbit that ties > the repository to the jcr-server. > > if you want to contribute your solution to oak that would > for sure be welcome. ah .. so basically it should be possible to hook in the old http binding but the plan is to finish this new http binding. meaning if someone wants to use the old http binding with oak it will always require a compiling a custom package, it will not be a question of changing some configuration setting. so in the long run it would be better for us to integrate with the new http api but this is currently not mature yet to support what we need. let me phrase the question slightly differently then .. how important is the new http api binding to the core oak dev team? from our understanding 2 years ago, the http api was supposed to have a higher priority than it had with jackrabbit 2.x but this is no longer the case? regards, Lukas Kahwe Smith [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
