The latest proposal was not about making nt:resource unreferenceable, but silently changing the resource type for a nt:resource child node of a nt:file node to Oak:Resource.
I just found three other places in Sling where nt:file nodes are created by hand. So with any other mechanism we have to change a lot of places in Sling alone. Not to mention all downstream users. Carsten Thomas Mueller wrote > 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 > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
