Hi,

On Thu, Mar 4, 2010 at 3:22 PM, Felix Meschberger <[email protected]> wrote:
> On 04.03.2010 15:14, Bertrand Delacretaz wrote:
>>...so we'd move from a JcrResourceTypeProvider
>> interface to a new ResourceTypeProvider one, that maps a Resource to a
>> path?
>
> If you mean the PathBasedResourceTypeProvider would have to migrated to
> take a Resource (and thus implement the new ResourceTypeProvider
> interface), then yes.

Yes that's what I mean.

>>
>> This would be not be backwards-compatible, so I think we need a vote
>> to remove JcrResourceTypeProvider - but adapting existing
>> implementations would be easy.
>
> I don't think we have to immediately start voting, if everybody is ok
> with the change....

I think a vote is needed if we want to remove the
JcrResourceTypeProvider interface, as that's a backward-incompatible
change (read on as to why I prefer removing it).

>
> ...In addition, we can keep the JcrResourceTypeProvider interface and mark
> it deprecated (to be removed sometime in the future) and implement a
> compatibility layer, which calls into the old JcrResourceTypeProvider
> services if the resource adapts to a node....

That would not work for the StarResource as that does not provide a
Node anymore, so we'd have a somewhat hidden incompatible change.

So I'd prefer removing the JcrResourceTypeProvider to make it clear
that things have changed, as opposed to keeping it with slightly
different semantics.

-Bertrand

Reply via email to