On 10/4/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...After the introduction of the topic by Carsten and some initial > discussion, I created issue SLING-28 [1] and committed a first > prototype. After having it around for some days now, I want to call for > a final discussion on this topic....
I thought about the request processing part a bit more, I'll try to summarize my ideas below. Note that I have purposely *not* looked at your proposed modified API - we'll see if my mental model matches the general idea! I *think* the model below more or less matches the current resource processing model, but makes it a bit more general and less dependent on JCR. Making it more generic and more plainly REST-oriented might help drive Sling acceptance, what do you think? ** The Sling request processing module (RPM) ** The RPM helps manage Resources in a REST way, using java code or scripted request processors. As HTTP Requests come in, they are pre-processed by a series of ServletFilters, to select the Resource to process, find out more about the client browser and locale, etc. The ResourceResolver filter selects the Resource that the current request applies to. The Resource is represented by an URL, using custom procotol handlers to map to the actual resource providers (for example, jcr:/default/content/mypage to point to a JCR repository resource). The ServletResolver selects the HttpServlet that will be used to process the Resource, and maps the Resource to a base (resource) path under which scripts can be found to process the request. Like Resources, Scripts are found and loaded using URLs and custom protocol handlers. The default SlingHttpServlet looks for a request processing script based on HTTP uniform interface names, like "get.jsp", "post.jsp" or "put.rb" or "delete.js", using a configurable order of possible script file extensions which map to script interpreters. This processing chain is built from OSGi bundles, to make each of its elements easy to implement, test and replace. -Bertrand
