jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Duck typing in Oak
Date Wed, 24 Apr 2013 12:59:10 GMT
hi jukka

as far as access control content is concerned that validation
is IMO required due to the fact that without the mixin type
on the parent the policy nodes would have a different declaring
node type which IMO is part of the contract defined by the
implementation... e.g. the repo could contain rep:policy nodes
that are basically invalid.

but while talking about the validators and commit hooks:

while taking a closer look at the permission evaluation i found
that the commit hooks and validators get informed about all
index updates which then get explicitly ignored by most
validators/hooks, except for those dealing with index update.

wouldn't it be possible to make it an explicit characteristic
of the commit hooks if they want/need to deal with hidden
trees and/or properties? IMO that would simplify the wast
majority of all hooks and significantly reduce the amount of
calls.

what do you think?
kind regards
angela



On 4/24/13 1:28 PM, Jukka Zitting wrote:
> Hi,
>
> As a part of my effort to streamline node type handling in Oak, I've
> encountered a number of cases where validators and other components
> explicitly check whether a node is of a given type before processing
> it further. For example the indexing code checks whether children of
> an oak:index node are of the oak:indexDefinition type, and the
> security code verifies that only rep:accessControllable nodes can
> contain ACLs.
>
> I wonder if we really do need such type checks. They increase
> implementation complexity and add extra performance overhead (though
> I've been able to cut down on that quite a bit) for no major benefit.
> Enforcing such type constraints would IMO be best left to the type
> validator that already has much better grasp of the available type
> information and is explicitly optimized for efficient type handling.
>
> Instead most of the other components that now validate such type
> information could simply rely on duck typing to figure out the meaning
> of the nodes they're processing. For example all children of an
> oak:index node could be interpreted as index definitions. The type
> validator (with some extensions about reserved names, etc.) could
> ensure the correctness of such assumptions so there would be no need
> to explicitly re-check the types of such content whenever it's
> accessed.
>
> BR,
>
> Jukka Zitting

Mime
View raw message