Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAOeqno0HAYPkqDu4aviKDi9KzkVygteCJAXHOYH1caukCY+vRw@mail.gmail.com>
References: 
 <CAHCW-mm2k0sChNmyZfJN0n9qnxoT8LM-pib=V5Vt+eXUSHm=FQ@mail.gmail.com>
	<CAOFYJNZY=JbfgM8sgTvuBPWPL7YcO9FQsoYinoFUzJsV6qM5Ag@mail.gmail.com>
	<CAEWfVJ=aLjNVDvfMSDPQB7sULfVht2XzQnX7riO2SpTOVh__uw@mail.gmail.com>
	<CAOFYJNYJxuhZgUZAsNdEyazOJsqRHYdiikFQtsNbGsGQY1Mfgg@mail.gmail.com>
	<CAKkCf4rouMZpyA1sVxQWLpo6MY5D-uy4+-TTR_YMe7q04GJrfQ@mail.gmail.com>
	<CAOFYJNYTrcm06TQmc_S+BTaK+r3ypzaGSagQtmyVNFBCcgXA9A@mail.gmail.com>
	<CAHCW-m=zq2vny5jEgVv8hJKp8JSJn-nCwO-vfu5XjkSHmmsacA@mail.gmail.com>
	<4EB438BF-5A8E-42C9-8979-A15B6C188896@adobe.com>
	<CAOFYJNaryQFs3zmr3HLYqH6Uf5qZnQeLy92cG+j_=GrWfqqc-w@mail.gmail.com>
	<09E6F8AA-776D-49FA-A546-63A958FD2F84@adobe.com>
	<CAOFYJNa5+8B3ZvwAQjRzTZQo2Aqk8F7W7a8otCna_tZnqjozFw@mail.gmail.com>
	<D35C15C2-8D94-4E7D-A3F5-9EFF0A11AE28@adobe.com>
	<CAOFYJNaddA=Y8-qZnM32hAfcenp6n+1PjPSHaSbrQ=-gELLt5w@mail.gmail.com>
	<CAKkCf4q9JPyL0L++4Ewb9zF2xwf42C=kczS==QE=Br3Vzd4bog@mail.gmail.com>
	<CAOeqno0HAYPkqDu4aviKDi9KzkVygteCJAXHOYH1caukCY+vRw@mail.gmail.com>
Date: Tue, 22 Oct 2013 16:39:11 +0200
Message-ID: 
 <CAKkCf4pwB-MTd0ZLSYT7n0pkuvM52DtJ-CaK-=f_c=tzdnME+g@mail.gmail.com>
Subject: Re: Oak JCR Observation scalability aspects and concerns
From: Carsten Ziegeler <cziegeler@apache.org>
To: oak-dev@jackrabbit.apache.org
Content-Type: multipart/alternative; boundary=089e01536b7c26460904e9555d65

--089e01536b7c26460904e9555d65
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just to reiterate :) if we go with 3 or 4, someone has to do the work in
Sling (and other places) and adapt the code. As obviously as soon as a
single listener is using the old pattern, the whole mechanism is mood.

Carsten


2013/10/22 Dominik S=FC=DF <dominik.suess@gmail.com>

> +1 on 4 since I fear 3 will create some overhead for existing solutions
> that won't need this kind of scalabilty (and therefore create uncessary
> efforts for migration).  This is the old "compat" pattern seen so often.
>
>  IMHO this should be an extension that "can" be installed but is not
> available by default (to force devs to decide on that but being lazy and
> not care about deprecation).
>
>
> On Tue, Oct 22, 2013 at 4:30 PM, Carsten Ziegeler <cziegeler@apache.org
> >wrote:
>
> > I really would like to have a constructive discussion here. I think the
> > Sling use case is pretty well explained now - that's an api Sling offer=
s
> > and which is used by a lot of code out there (a great part of Sling is
> > based on the OSGi events and layers on top of Sling are using it as
> well).
> > That's a fact and it's also a fact that listeners for the OSGi event
> > usually listener for all events.
> >
> > Now basically we have three/four options:
> > 1. we leave everything as is - it works but might be slow with larger
> > installations and heavy writes
> > 2. we maintain the API as-is in Sling and try to make the implementatio=
n
> as
> > fast as possible
> > 3. we break compatibility in Sling, find a better solution, rewrite par=
ts
> > of Sling and require all downstream users to rewrite their stuff
> > well, the fourth option would be
> > 4. same as 3. but keep the old Sling API with a bold marker when it's
> used
> > that this does not scale
> >
> > For the sake of compatibility I really would like to go with 2 which
> might
> > require changes in Sling and Oak but sounds to me as the best compromis=
e.
> > In addition, it really would help the discussion if we would have
> > performance tests showing us the real boundaries in terms of scalabilit=
y
> > with observation with some real figures.
> >
> > Thanks
> > Carsten
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
>


--=20
Carsten Ziegeler
cziegeler@apache.org

--089e01536b7c26460904e9555d65--