jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [j3] Repository MicroKernel API draft
Date Mon, 20 Jun 2011 12:27:13 GMT
On Mon, Jun 20, 2011 at 12:43 PM, Michael Dürig <mduerig@apache.org> wrote:
>
>> agreed. since the audience of the MicroKernel API is pretty small
>> programmer-friendliness has admittedly not been a top priority ;)
>
> I think programmer-friendliness should have a higher priority then. Where
> did this priorities come from btw?

those priorities reflect my personal judgement, based on various coffee break
discussions, mailing-list discussions and 10 years working on jackrabbit core.

i've started the sandbox project to share it with interested parties
in the community
and hoping to be able to test the feasibility of this approach.

cheers
stefan

>
> Programmer unfriendly api's lead to programmers designing ad-hoc convenience
> wrappers which lead to fragmentation and broken windows. This is already now
> apparent from the jr3 prototype code base! Which is pretty alarming to me.
>
>> OTOH portability, remotability, stateless nature and compactness
>> have been. having those goals in mind, JSON is IMO a perfect fit.
>
> Again, where did these goals come from? What are the rationals?
>
> While I think having a stateless api is a good think, I think we should not
> let this preclude other features and functionality. For example having the
> commit method to contain all the transient changes in a single json string
> will limit the size of transient modifications.
>
> We could as well allow transient changes to be written to the micro kernel
> and then committed later on:
>
> changes.add(mk.writeTransient("+/foo/bar, {}"))
> changes.add(mk.writeTransient("+/foo2/bar2, {}"))
> ...
> mk.commit(changes)
>
> IMO this is as stateless as the other approach.
>
> Michael
>
>
>
>>
>> cheers
>> stefan
>>
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>

Mime
View raw message