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:57:16 GMT
On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger <fmeschbe@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 <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.

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
>

Mime
View raw message