Yes, backwards compatibility is important and I think if we introduce
new methods in the ResourceResolver (deprecating the old ones), we'll
get that easily. For now, I wouldn't introduce a different content model
for the mapping in /etc - that could be done independently if required
Regards
Carsten
Am 24.08.2020 um 10:21 schrieb Bertrand Delacretaz:
Hi,
On Sun, Aug 23, 2020 at 11:24 AM Carsten Ziegeler <cziege...@apache.org> wrote:
...PathMapperFactory (its probably not a good name...
I think "rewriter" instead of "mapper" might be a good term, in the
end it's similar to the famous mod_rewrite?
...So how about moving the mapping part out of the resource resolver? As
we've seen recently other parts of Sling like auth core could benefit
from this as well...
I think that makes sense but I'm not sure how we can guarantee
backwards compatibility if we do that.
We might need to keep the existing mechanisms in parallel, but deprecate them?
The "global" configs in /etc/map might be a problem then but we could
move that to /etc/rewrite and design the new rewriter to ignore
/etc/map if a rewrite already happened. So that Sling users can turn
off /etc/map after some time, once counters or logs show that it's not
used anymore in their setup.
...This way we have a clear separation between mapping and resolving and
in which contexts the operations happen....
I like that, assuming we can cleanly take care of backwards compatibility.
-Bertrand
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
