AW: Using OAK in a production environment.

Hi Laura .. I can only agree with Julian. We have similiar the same architecture as you described and we have Millions of documents in jackrabbikt without any performance problem. About OAK and JCA I can't tell much because I am at the moment not so deep in oak, but I think nobody has tested

AW: Cleanup NodeStore and MK implementations (was: Re: AW: Confusions about API's and Flavours in the documentation ...)

hi angela, +1 for anything that clears that mess !! separating the two storage concepts is ok for me and also to move the MK code in a sandbox project ... on the other hand we should then update the documentation so that the people are not so confused about the wording/architecture .. greets

AW: Confusions about API's and Flavours in the documentation ...

Hi, Ok thanks for your feedback ... And yes, it's confusing. .. so I'm not alone here :-) I would change the documentation to better fit the right terms. greets claus

AW: [VOTE] Release Apache Jackrabbit Oak 1.0.0

+1 greets claus P.S Good Work !!! -Ursprüngliche Nachricht- Von: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] Gesendet: Montag, 12. Mai 2014 22:23 An: oak-dev@jackrabbit.apache.org Betreff: Re: [VOTE] Release Apache Jackrabbit Oak 1.0.0 [X] +1 Release this package as Apache

AW: Partitions! (Was: Workspaces, once more)

Hi Jukka, We are using jackrabbit / oak not in that way crx is using it. Seeing workspaces as partitions can be ok .. for me it's only a definition. We are using workspaces as a separation of the whole repository where each client have its place to store documents without the opportunity to see

AW: writing a new DocumentStore implementation

Hi Thomas, Sounds good to me !! One question based on that topic. As jukka described with the big-picture the BlobStore we are talking is only used with mongo-mk as I can see, but what's about the segment-mk.. is it planned to have a SQL based Segment Store ? greets claus

AW: AW: writing a new DocumentStore implementation

Hi Thomas, That brings a lot of light in my head :-) I didn't know that the Mongo Storage is not bind to a Mongo DB at all. It would be cool to have a Document-Store (Document-MK ?) that either stores it's nodes/blobs in a mongo db or in a sql db. Based on our requirements to jackrabbit, to

AW: writing a new DocumentStore implementation

Hi .. I would like to jump in to that topic ... For me it's also not so easy to have the global view about DocumentStore, NodeStore, BlobStore and the plan to bring the old DataStore from jackrabbit to oak ... There also a SQLBlobStore in oak-core and a DBBlobStore in oak-mk. Why are they in

AW: AW: writing a new DocumentStore implementation

Hi Julian, Nice to hear that i'm not the only out there who has lost the overview :-) The DBBlobStore is a H2BlobStore or ? I'm asking because I would like to see or implement a OracleBlobStore ... greets claus

AW: writing a new DocumentStore implementation

Hi Jukka, Thanks for clarification ! Are the different stores historically emerged or do they have simply different functions ? and where will the Jackrabbit DataStore fit in ? greets claus

AW: The destiny of Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)

i'm feeling absolutly with angela. like angela said I would also be afraid that jackrabbit has no future ... what if we made it like the j2ee profiles. there is a full compliant profile but also some lighter profiles. we can make also profiles so that people can choose which profile they want

AW: [VOTE] Accept MongoMK contribution (Was: [jira] [Created] (OAK-293) MongoDB-based MicroKernel)

+1 greets claus