Again: can we please have sling debates on dev@sling ? Thanks Felix
Von meinem iPad gesendet > Am 22.10.2013 um 16:39 schrieb "Carsten Ziegeler" <cziege...@apache.org>: > > 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
