I'm with Julian R. on this (as I understand him). We should change the node-type nt:resource to match the JCR 2.0 spec and deal with the consequences.
Currently I am under the impression that we have no knowledge of what *might* break, with varying opinions on the matter. Maybe we should to find out what *does* break. As a remedy for implementations that rely on the current referencable nature, we could provide tooling that automatically adds the "mix:referencable" mixin to existing nt:resource nodes and recommend adapting the code to add the mixin as well. Regards Julian On Wed, Oct 12, 2016 at 11:04 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > 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 >
