Hi, I agree with Julian, I think making nt:resource unreferenceable would (hardcoding some "magic" in Oak) would lead to hard-to-find bugs and problems.
> So whatever solution we pick, there is a risk that existing code fails. Yes. But I think if we create a new nodetype, at least it would be easier for users to understand the problem. Also, the "upgrade path" with a new nodetype is smoother. This can be done incrementally, even thought it might mean more total work. But making nt:resource unreferenceable would be a hard break, and I think risk of bigger problems is higher. Regards, Thomas On 07/10/16 12:05, "Julian Reschke" <julian.resc...@gmx.de> wrote: >On 2016-10-07 10:56, Carsten Ziegeler wrote: >> Julian Reschke wrote >>> On 2016-10-07 08:04, Carsten Ziegeler wrote: >>>> ... >>>> The easiest solution that comes to my mind is: >>>> >>>> Whenever a nt:resource child node of a nt:file node is created, it is >>>> silently changed to oak:resource. >>>> >>>> Carsten >>>> ... >>> >>> Observation: that might break code that actually wants a referenceable >>> node: it would create the node, check for the presence of >>> mix:referenceable, and then decide not to add it because it's already >>> there. >>> >> >> Well, there might be code that assumes that a file uploaded through >> webdav is using a resource child node that is referenceable. >> Or a file posted through the Sling POST servlet has this. Now, you could >> argue if that code did not create the file, it should check node types, >> but how likely is that if the code has history? >> >> So whatever solution we pick, there is a risk that existing code fails. >> ... > >That is true.. > >However, my preference would be to only break code which is >non-conforming right now. Code should not rely on nt:resource being >referenceable (see ><https://docs.adobe.com/content/docs/en/spec/jcr/2.0/3_Repository_Model.ht >ml#3.7.11.5%20nt:resource>). > >So my preference would be to make that change and see what breaks (and >get that fixed). > > > ... > > >Best regards, Julian