Hi, Since the initial message created quite a stir and since I was offline when the reactions started coming up, I owe you some clarifications.
> There are 2 hard problems in computer science: cache invalidation, naming > things, and off-by-1 errors. The naming of the module might not be the most accurate; we’re going to have to think about it together if the module is ever going to “graduate” from the whiteboard. The thing is that the code does some script resolution, manages servlet registrations, manages request dispatches, etc. As mentioned before the module is an add-on. It doesn’t change anything in Sling and installing it on an instance doesn’t cause any side effects. In order for this module to actually do something, bundles providing scripts have to be wired to it (by explicitly requiring one of the resolver’s capabilities) and on top of that these script bundles have to also provide a “sling.resourceType” capability plus scripts packed according to some conventions. When these conditions are met, then the resolver will register Sling servlets for the “sling.resourceType” capabilities it finds. Therefore, to answer Bertrand’s question, if two identical resource types will be registered from different places (e.g. repository scripts / servlets) the Sling engine is the one deciding which to use, based on the existing conventions. What Karl and I have done is indeed a redesign of how scripting could work, but given that the module is an add-on one could still deploy scripts in both ways on an instance. We’ve done our best to document how things work with the add-on, so playing a bit with the provided examples [1] might clear some of the concerns / answer some of the questions. However, please feel free to dissect the code and its purpose. Regards, Radu
