Hi, On 27.08.2010 14:49, Alexander Klimetschek wrote: > 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...
I'd rather not want to ... (unless it makes really good sense) > > 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. AbstractSlingPostOperation is public and exported from the Sling POST Servlet bundle. So there is no reason not to extend from it. And actually, for extensions of the AbstractSlingPostOperation a recompilation is not even required because thanks to Java late binding, this just works. > > 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 Yes, but I want to do it right the first time .... ;-) Event if it takes a day longer initially. > >>> 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 >
