Even though I said (and still think) that the SlingPostOperation interface is defined to be able to inject new functionality into the SlingPostServlet and probably should only be used by the SlingPostServlet it might be possible to call SlingPostOperation services from outside the SlingPostServlet.

The easiest thing would be to just register all predefined operations as services, which would also be consumed by the SlingPostServlet itself. Since the SlingPostServlet can register these services itself, there is no issue for setting these (particularly for the ModifyOperation or the ImportOperation).

But, if we are at it: How about fixing another issue itching my back every now and then: The HtmlResponse class is an extremely strange biest -- and probably not correctly located in the Sling API bundle (from today's perspective, at least).

So here is my full proposal:

1. Create new response helper classes (replacing HtmlResponse): AbstractHttpResponse -- help gather changes, status, etc. and has abstract send method. HtmlHttpResponse -- implements send method generating HTML JsonResponse -- implements send method generating JSON

2. Create a new PostOperation interface with a slightly different API than today's SlingPostOperation:

// the SlingPostProcess[] may be null void run(SlingHttpServletRequest, AbstractHttpResponse, SlingPostProcess[])

3. Create an AbstractPostOperation analogous to the AbstractSlingPostOperation

4. Refactor predefined operations of the Sling POST Servlet bundle to the new interface and register them as services

5. For backwards compatibility, provide a service proxy for existing SlingPostOperation services. The SlingPostOperation interface and AbstractSlingPostOperation abstract class are deprecated.

WDYT ?