jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 09:34:46 GMT
hi felix

from what i see Sling heavily relies on jackrabbit-core functionality...
i would be very pleased if it would just rely on public API such as JCR,
Jackrabbit API and in the future OAK; it doesn't and this is causing a
lot of troubles.

kind regards
angela

On 10/22/13 11:21 AM, "Felix Meschberger" <fmeschbe@adobe.com> wrote:

>Hi
>
>Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra:
>
>> On Mon, Oct 21, 2013 at 11:39 PM, Jukka Zitting
>><jukka.zitting@gmail.com> wrote:
>>> 3) The Observer mechanism allows a listener to look at repository
>>> changes in variable granularity and frequency depending on application
>>> needs and current repository load. Thus an Oak Observer can
>>> potentially process orders of magnitude more changes than a JCR event
>>> listener that needs to look at each individual changed item.
>> 
>> +1
>> 
>> I think in Sling case it would make sense for it to be implemented as
>> an Observer. And I had a look at implementation of some of the
>> listener implementations of [1] and I think they can be easily moved
>> to Sling OSGi events
>
>To be discussed on the Sling list -- though wearing my Sling hat I am
>extremely weary of implementing an Oak-dependency in Sling. Sling uses
>JCR.
>
>Regards
>Felix
>
>> 
>> Chetan Mehrotra
>> [1] 
>>https://gist.github.com/chetanmeh/7081328/raw/listeners-list-filtered.txt
>


Mime
View raw message