jackrabbit oak support about jackalope-jackrabbit HOT 12 OPEN

see this thread for some hints on how to configure oak with the old http api
http://mail-archives.apache.org/mod_mbox/jackrabbit-oak-dev/201407.mbox/%[email protected]%3E

from jackalope-jackrabbit.

Hi there - i see there are now regular releases of OAK and I am wondering if there is any progress on the HTTP api side? from what i understood its there but it does not support the multi - fetches used by jackrabbit. Are they planning to do this or will jackrabbit need some refactoring?

from jackalope-jackrabbit.

the "old" jackrabbit remoting layer should work with oak but needs to be bundled which exceeds my java skills. somebody would need to dig into that and have a jar / war file that can be run with oak and the jcr remoting of jackrabbit. then we could see with the tests if that works or not.

but in other news, oak is starting to think about adding a REST layer for remoting access. @lsmith77 and me will meet adobe people tomorrow to discuss that. the first draft idea is at https://github.com/francescomari/oak-remote

from jackalope-jackrabbit.

one of probably many things to look at is https://issues.apache.org/jira/browse/OAK-533 - maybe oak will do something different with mix:lastModified

from jackalope-jackrabbit.

hi @dbu - were there any recent development on the rest layer of oak?

from jackalope-jackrabbit.

Hi. Have you made any progress on Oak or decided to cancel this one ?

from jackalope-jackrabbit.

we have not invested anymore time into this .. afaik the Oak HTTP interface is making good progress .. so it just needs someone to put int the time.

from jackalope-jackrabbit.

Isn't Oak a drop-in replacement for Jackrabbit 2.x? Or does there need to be an implementation to support it in jackalope?

from jackalope-jackrabbit.

the JCR specification does not change for oak, but in jackalope-jackrabbit we do not call java. instead, we use the jackrabbit remoting protocol which is not part of any official standard. it turned out that its possible to wrap the jackrabbit remoting to jcr layer around oak, but there seem to be no official distributions of this set up. and when we tried, there where a few differences like oak did not support multiple workspaces. see also #109

the oak people where also talking about a new, cleaner remoting protocol for oak. if we could dock to that, a new Client would need to be written, but it hopefully could look a lot cleaner. i did not follow up on things there recently, being busy with keeping the cmf up to date with symfony 2.7 and now 3.0. if you are interested in working on this, i can look for the current state of the oak remoting and try bring you into contact with the oak/jackrabbit people that helped us in the past.

from jackalope-jackrabbit.

I see OAK now has an HTTP api. In this repository, there is two oak branch but seems abandoned-ware. Any plan for OAK transport implementation?

from jackalope-jackrabbit.

not that I am aware of but it would be awesome to have this!
note this might also be an opportunity to further move the current transport API away from being based on the old Jackrabbit XML API.

from jackalope-jackrabbit.

i also would not know of anybody currently working on that. if you want to give it a go, please do. either based on the current Transport implementation or with a cleaned up approach that would end up being a version 2 of jackalope.

from jackalope-jackrabbit.