On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger <fmesc...@adobe.com> wrote: > Hi, > > Am 27.06.2012 um 11:20 schrieb Jukka Zitting: > >> Hi, >> >> On Wed, Jun 27, 2012 at 10:25 AM, Angela Schreiber <anch...@adobe.com> wrote: >>> i don't fully see the use case for such long living sessions. > > FWIW, this was my first thought, too: This completely breaks stateless-ness > of HTTP and introduces the use of Sessions. We can do that, but we have to > know exactly, what it means and costs. > >> >> 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. > > With my Sling hat on, I am not sure about this example ;-) > > IMNSHO Sling should operate on JCR API and not on Oak Native HTTP binding.
for once i'm a 100% with felix ;) if i understand jukka's proposal correctly, it's about promoting an alternative public client api. in my understanding the ultimate goal of the oak project is to come up with a highly efficient & scalable jcr implementation. imo we should focus on this goal. i thought that we have a consensus of how the oak stack should be layered, i.e. app / sling / oak-jcr (trans. space) / [remoting /] oak-core [remoting /] oak-mk. now your proposal seems to imply a different architecture... cheers stefan > > Regards > Felix > > >> >> 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 >
