I think approach b) has a couple of short comings for larger sites as well
a good example are bucket pages (say you have to bucket content because
otherwise you have to many subnodes). I've seen sites where these bucket
pages are removed from the urls.
a secondary issue is that the upstream caching mechanism does not know
about the mapping and therefore has trouble caching pages in a good
manner (suffix and selector based pages)
I would honestly prefer an option c)
where
1) sling can be asked to resolve a short url to a long url (in
conjunction with an apache module that can use this resolution for caching)
2) use a rewrite pipeline for outgoing url changes (there are also use
cases for serving assets from a static domain)
Ruben
On 4/19/2016 6:18 AM, Bertrand Delacretaz wrote:
On Tue, Apr 19, 2016 at 3:12 PM, Julian Sedding <[email protected]> wrote:
...The whole mapping business is overly complicated IMHO and any reduction
of the complexity is welcome....
Indeed. I would suggest that people who are actively managing large
Sling instances in the field (hint, hint ;-) come up with proposals
about how to simplify the whole thing.
-Bertrand
