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.
Thomas Mueller wrote
> I agree with Julian, I think making nt:resource unreferenceable would
> (hardcoding some "magic" in Oak) would lead to hard-to-find bugs and
>> 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.
> 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.
>>>> 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
>>> 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
>> So my preference would be to make that change and see what breaks (and
>> get that fixed).
>> Best regards, Julian
Adobe Research Switzerland