Hi Vidar, Vidar Ramdal schrieb: > On Fri, Nov 21, 2008 at 8:16 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> [...] >> The sling:vanityPath property is multi-valued and contains URLs. These >> URLs may be absolute or relative. An absolute URI includes the scheme, >> authority and path. A relative omits the scheme and or authority part. >> In additiona relative URI may even be a relative path. >> >> To resolve a request URL with Host: header and path, the resource >> resolver would first check whether there is an exact match for the path >> in the repository. If not, the resource resolver will then -- from the >> top of the resource tree -- look for a resource whose sling:vanityPath >> matches the Host: header plus (optionally) any prefix of the path. From >> there the path would be traversed down along resource names and relative >> sling:vanityPath entries to find the final resource. >> >> This _is_ expensive and therefore absolutely requires caching. >> Therefore, we will introduce a small (something like 1000 entries or >> so), which may be used to directly map incoming requests to resources. >> The cache is managed very simply: on each change in the resource tree, >> the cache is just dropped. > > I'm not thrilled about the idea of dropping the cache on every change. > In our application, there will be changes maybe every minute, > effectively leaving the cache unusable.
There are two caches actually: One cache manages the values of sling:vanityPath properties, which may be used as the domain root or root path. This cache is of course not flushed on each modification in the repository. Rather this cache is managed by listening to sling:vanityPath modifications and updating to the point information. The other cache will cache actual resolutions of request URLs to resources. Since this may also be a time-consuming job optionally involving reading multiple sling:vanityPath properties. This second cache is -- probably -- very hard to maintain just by listening to sling:vanityPath changes. For this reason, I think it is ok to start with a "clear on modification" approach. We may still implement a more intelligent cache later, should we find out, that the cache hit-ration is to low. > > Is there a significant benefit of adding domain resolution to the > vanityPath system, as opposed to having a different mechanism for > domains? Yes, it makes handling easier: We have one singly property which takes four easily distinguishable values: * absolute uri: starts with scheme:// * relative uri with host: starts with // * absolute path: starts with / * relative path: everything else So, we can easily decide upon reading the property, what actually it is. For the author it is easier, since she only has to manage one property. Of course, over time, it may get confusing if many sling:vanityPath properties are set. I think to cope with that, we can provide a "management" interface (thinking of Felix Web Console integration right now), which may show domain and path roots. > I would think it would be less expensive to > a) Restrict the location of domain roots to a specified location > (let's say /domains). Then the domainroot cache could just observe > /domains for changes, and would not have to be dropped on every change > in the tree As said above, the roots are cached and managed by intelligent observation listening for sling:vanityPath changes. So we can cope with this problem. > - or - > b) Use a separate mixin nodetype for domainroots, and let the domain > cache observe the nodetype (see Bertrands comment at [1]) > > (I haven't looked much into the vanityPath system, so maybe it would > have to be rewritten anyway domainroots are implemented.) The current code cannot be used for the new approach, because it has a much simpler use case, since currently sling:vanityPath values are just absolute path strings. Hope this helps. Regards Felix > > [1] > https://issues.apache.org/jira/browse/SLING-249?focusedCommentId=12649425#action_12649425 >
