jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Native HTTP bindings for Oak
Date Wed, 27 Jun 2012 09:49:31 GMT
Hi,

Am 27.06.2012 um 11:20 schrieb Jukka Zitting:

> 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.

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.

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


Mime
View raw message