On Tue, Oct 4, 2016 at 11:01 AM, Carsten Ziegeler <[email protected]> wrote: > What about if the node type is changed by default in Oak? This seems to > be according to the spec. > The problem might then only be with old installations and for this you > can provide a switch. Maybe somehow even detecting the situation.
This has been discussed earlier also [1]. Also concern was raised in spec update itself [2] that such a change is backward incompatible. Its like changing an existing interface. So any code which rely on nt:resource being referenceable would fail. Remember any change in nodetype definition is global. Changing at Sling Level ================== Change here would be more manageable. Per spec nt:file would have a child node which is having name 'jcr:content'. Spec does not mandates any nodetype for this. It can be nt:resource, nt:unstructured or oak:Resource. [3] ---------------- ... requires a single child node called jcr:content. The jcr:content node is used to hold the actual content of the file. This child node is mandatory, but not auto-created. Its node type will be application-dependent and therefore it must be added by the client. ---------------- So application is free to choose the nodetype for jcr:content node Config Complexity ================== > I fear we're creating a monster of configurations here and there Lets see. Proposal here is to change the defaults 1. Have webdav use oak:Resource as default if repository has that nodetype 2. Have SlingPostServlet use oak:Resource as default if repository has that nodetype - a config switch to revert back to old behaviour if application code relies on fact that 'jcr:content' node in nt:file is always of type nt:resource In both cases the end user does not have to change any default setting unless required. > although the problem itself can be easily solved at the base. Had compatibility been not a concern that would have been an option. However as explained above doing that would be a backward incompatible global change. While changes being proposed are valid per spec (jcr:content can be any nodetype) and change is much more controlled (config switches to revert back to old behaviour in case) and is scoped to Sling part Its just like StringBuilder is better than StringBuffer in most cases but even then it was introduced as a new class and semantics of StringBuffer were not changed :) To reiterate I am just aiming for a solution here which enables a user to use a more optimum nodetype and get best performance out of underlying repository. Chetan Mehrotra [1] http://markmail.org/thread/uj2ht4jwdrck7eja [2] https://java.net/jira/browse/JSR_283-428 [3] https://docs.adobe.com/content/docs/en/spec/jcr/1.0/6.7.22.6_nt_file.html
