jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Native HTTP bindings for Oak
Date Wed, 27 Jun 2012 11:50:35 GMT
Hi,

I understand the point Felix is making. As of now, I would propose to drop
separate URI spaces.

I would also propose to drop the related MicroKernel branch/merge feature,
or at least not rely on the feature to be available. In my view, the
MicroKernel branch/merge feature which was introduced (relatively)
recently adds quite a bit of complexity to each MicroKernel implementation.

As far as I know, one reason why branch/merge was introduced was to reduce
complexity in oak-core, but the reduced complexity in oak-core increased
the complexity in each MicroKernel implementation. So we traded reduced
complexity of one part (one oak-core implementation) with added complexity
in many parts (multiple MicroKernel implementations).

The second reason why branch/merge was added is to support commits that
don't fit in memory. This is, if I remember correctly, not one of the
goals originally defined for Oak. We documented a goal of "> 100k nodes at
1kB each" at [1], that is 100 MB. That should fit in memory.

[1] 
http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrab
bit%203

Regards,
Thomas





On 6/27/12 12:13 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger <fmeschbe@adobe.com>
>wrote:
>> FWIW, this was my first thought, too: This completely breaks
>>stateless-ness
>> of HTTP and introduces the use of Sessions.
>
>I think you're misreading the proposal. The feature uses separate URI
>spaces so all information needed to access such "sessions" is encoded
>in each request and depends on no shared state between the client and
>the server.
>
>> With my Sling hat on, I am not sure about this example ;-)
>
>I'm just using Sling as an concrete example of an existing complex
>client. A JavaScript application or another remote client could easily
>have just as complex content access requirements, and I think it would
>be good for us to be prepared for such cases.
>
>BR,
>
>Jukka Zitting


Mime
View raw message