Okie. So I have started a new mail thread addressing both project teams to see if we can converge on some agreement here. Kindly provide your feedback there
Chetan Mehrotra On Tue, Oct 4, 2016 at 11:55 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > Thanks Chetan, > > I'm really wondering if there can't be a better solution :) > > For example, look at the jcr classloader module, writing class files to > the repository. It creates a nt:file with a nt:resource child node. > While jcr classloader is not that important nowadays anymore, I think we > have several of those places in our code base. I understand that we > don't have to change all those places, but I assume the optimum would be > that whenever such a jcr:content child node is created, you use > oak:resource as the node type - unless there is a really good reason to > make it referencable. But being realistic, has there ever been a use > case for this? > > While we could change the post servlet and add the check, I definitely > don't want to add such a check all over our code base, then thinking of > our downstream users, they would have to do the same. > > Carsten > > Chetan Mehrotra wrote >> On Tue, Oct 4, 2016 at 11:01 AM, Carsten Ziegeler <cziege...@apache.org> >> 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 >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
