hi jukka

On Wed, Jun 27, 2012 at 10:25 AM, Angela Schreiber<[email protected]>  wrote:
i don't fully see the use case for such long living sessions.

The rationale is the same as for the branch feature we added to the
MicroKernel. Instead of having to maintain a separate transient tree
abstraction on the client side (which might be troublesome given
potentially limited storage capacity), it's better to be able to send
uncommitted data to the server for storage in a temporary branch where
it can be accessed using the existing tree abstraction already
provided by Oak.

Most notably the session feature allows us to use such a HTTP binding
to implement remoting of the Oak API without the need for client-side
storage space and associated extra code for managing it.

well.... that's pretty much matches my very first mapping of JCR to
HTTP (using WebDAV) and it showed that having such a lazy client
didn't work out very well... at the end we ended up inventing JSOP
i.e. the various ways of batch reading and writing including the
diff-pattern that allowed to persist a bunch of changes in a
single commit.

the whole story of the SPI and that extra layer we are having
now in oak (compared to jackrabbit 2) was/is that we want to be
able to have different non-java content repository layers such
as the php implementation with the aim to delegate the transient
part to those clients instead of keeping track of the transient modifications on the server.

kind regards
angela

Reply via email to