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üß <dominik.su...@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 <cziege...@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 offers > > 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 implementation > as > > fast as possible > > 3. we break compatibility in Sling, find a better solution, rewrite parts > > 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 compromise. > > In addition, it really would help the discussion if we would have > > performance tests showing us the real boundaries in terms of scalability > > with observation with some real figures. > > > > Thanks > > Carsten > > -- > > Carsten Ziegeler > > cziege...@apache.org > > > -- Carsten Ziegeler cziege...@apache.org
