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.
>>>> 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
>So my preference would be to make that change and see what breaks (and
>get that fixed).
> > ...
>Best regards, Julian

Reply via email to