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" <[email protected]> wrote: >Hi, > >On Wed, Jun 27, 2012 at 11:49 AM, Felix Meschberger <[email protected]> >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
