Hi all, Currently the SlingServlet is a very simple interface defining doXXX methods for some HTTP request methods and a canProcess method to ask whether the SlingServlet is willing to process the request. I think, this interface is not required as is. I discussed this quickly with Bertrand yesterday, and we came up with the idea of a SlingGetServlet and a SlingServlet.
The SlingGetServlet would also provide API for the GET and HEAD methods, the SlingServlet would add support for the rest of the core HTTP methods like OPTIONS, TRACE, POST, PUT and DELETE. And finally, an extension of SlingServlet could add support for more methods, for example a SlingDAVServlet might add support for WebDAV methods like MKCOL, etc. While we agree that it is a good idea - also from a educational point of view - to have such servlets with precanned doXXX methods, we do not actually agree, where the selection of the doXXX method should be located. Bertrand thinks along the ways of the current microsling SlingServlet, which just has the doXXX methods and some core class in Sling select the doXXX method based on the request method (and optional method overwrite). I think along the lines of the javax.servlet HttpServlet class, which implements this dispatching in the service method with an important difference, of course: We would not simply throw on a method not directly known but dispatch to a doGeneric method, which by default throws of course. What is your opinion on this: A separate SlingServlet interface/class hieararchy or going along the lines of the HttpServlet (yet doing it better with respect to non-core HTTP methods) ? Regards Felix
