On Thu, Jul 19, 2012 at 11:09 AM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Thu, Jul 19, 2012 at 10:18 AM, Stefan Guggisberg > <[email protected]> wrote: >> implementing the transient space in Oak-Core is >> legitimate, although premature optimization for >> the specific use case where the entire stack >> (jcr-...-mk) runs in the same vm. > > To clarify, the decision to write changes from oak-jcr directly to > oak-core was not driven by performance ("premature optimization") but > rather by the need a) to in any case have those changes in oak-core > for validation, etc. and c) to support large content imports that > wouldn't necessarily fit into memory. We also wanted to avoid having > to write essentially the same code twice for oak-core and oak-jcr. The > performance benefit of reduced amount of internal copying and memory > overhead is just a nice side-effect of the design.
a) in scenarios where the Oak-API is remoted we'll have to buffer transient changes on the client and batch-write them to the 'server' (Oak-API impl). handling the transient space exclusively below the Oak-API is IMO not an option for this use case. c) (or rather b) ?) large content imports should IMO be done through javax.jcr.Workspace#import. there's an equivalent functionality in the old SPI and it should IMO be exposed in Oak-API as well. cheers stefan > > See the mentioned list archives of March/April for more background, > with [1], [2] and [3] being good starting points. > > [1] http://markmail.org/message/uficvjx35cxy5h4i > [2] http://markmail.org/message/panl3wxfekvmcfyw > [3] http://markmail.org/message/m7linbldpirjz2bn > > BR, > > Jukka Zitting
