sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Müller <>
Subject RE: [VOTE] Moving SLING-2396 to trunk
Date Mon, 11 Jun 2012 13:53:13 GMT
Hi Carsten

Thank you for bringing up this again.
A think this major change could bring Sling a lot forward and
maybe gives us the chance to get a broader user base.
And making things independent from each other is a good
idea anyway ;-)

so, a big +1

best regards

> -----Original Message-----
> From: Carsten Ziegeler []
> Sent: Sunday, June 10, 2012 5:19 PM
> To:
> Subject: [VOTE] Moving SLING-2396 to trunk
> Hi,
> I really would like to move forward with SLING-2396 (Make
> ResourceResolverFactory independent from JCR) in order to implement
> other features (like CRUD support for the resource resolver) on top of
> this.
> Unfortunately this change introduces an incompatibility wrt
> workspaces, therefore I thought it's safer to call a vote and see what
> the community things about it.
> The vote is not about implementing SLING-2396 in exactly the way it is
> right now, its just to move the code to trunk and continue to work
> there.
> For the workspace support, right now, it's possible to address other
> workspaces by specifying an artificial path {workspacename}:{/path} .
> This won't be possible anymore, however it would be possible to mount
> a workspace at any path in the resource tree (and that would happen on
> demand).
> I think, if someone really needs the special path access to a
> workspace like it is today, then we could add a wrapper for the
> resource resolver which does this special logic in the wrapper.
> However, if we don't need it, i don't want to spent time on that :)
> I think SLING-2396 is one of the most important changes to our code
> base, which will make it easier to implement new features in the
> resource resolving area, e.g. we get adding different search providers
> for free etc.
> Please vote, thanks :)
> Regards
> Carsten
> --
> Carsten Ziegeler

View raw message