Hi, 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. > IMO also importing big trees and batch read/writing should be covered > by a single request. That quickly leads to increasingly complex server side features like filtering or conditional saves. For example, think of a client like the Sling engine that first resolves a path potentially with custom mappings, then follows a complex set of resource type references, and finally renders a representation of the resolved content based on the resource type definitions that were found. Ideally (for consistency and better caching support) it should be possible to perform the entire operation based on a stable snapshot of the repository, but there's no way that all the information required by such a process could be included in the response of a single Oak HTTP request. Exposing the branch feature as proposed avoids the need for complex server-side request processing logic and makes it easier to implement many client-side features that would otherwise have to use local storage or temporary content subtrees visible to other repository clients. BR, Jukka Zitting
