jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Native HTTP bindings for Oak
Date Wed, 27 Jun 2012 12:41:05 GMT
On Wed, Jun 27, 2012 at 11:20 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Wed, Jun 27, 2012 at 10:25 AM, Angela Schreiber <anchela@adobe.com> 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),

are you saying that each Node.addNode would trigger a sever-roundtrip?
i don't see how this could perform reasonably...


> 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

View raw message