On Fri, Aug 27, 2010 at 13:22, Felix Meschberger <[email protected]> wrote: > The problem is with existing implementations: If we extend the interface > we break existing implementations of the interface. > > We could do though: > > * Add a new interface SlingPostOperation2 extends SlingPostOperation > * AbstractSlingPostOperation implements SlingPostOperation2 > > Thus extensions of the AbstractSlingPostOperation are > SlingPostOperation2 for free. Plain implementations of > SlingPostOperation still have to be supported with a proxy.
Ah, yes. But I think this could be one of the breaking changes... This would have been better if AbstractSlingPostOperation would be public and custom implementations would most likely inherit from it, making the transition just a recompilation. However, we are talking about two things that can be done separately: - make the operations available as services (no API breakage) - change the API to the new response interface >> For the "interesting" stuff, like NodeNameGenerator or MediaRangeList >> and co, I'd suggest to move them to public locations in >> commons-style-libraries, such as jackrabbit-jcr-commons or >> (I-don't-know-yet), to make them publicly available. > > jackrabbit-jcr-commons is an uncontrollable biest .. ;-) So I'd rather > not put stuff there, esp. not Sling specific or Web App specific stuff. jackrabbit-jcr-commons was meant for the NodeNameGenerator, MediaRangeList would go somewhere else. But especially that thing could be useful for implementing strict RESTful servlets, that should operate on the Accepts header, something which isn't very much supported in Sling so far. But this is quite OT now. Regards, Alex -- Alexander Klimetschek [email protected]
