I fully agree. The script resolver should probably leverage the resource type hierarchy service you suggested previously.
Regards Julian On Thu, Mar 24, 2016 at 8:39 AM, Carsten Ziegeler <[email protected]> wrote: > Hi, > > the way the current script cache works is really not optional: it takes > information from the request as the key, namely the extension, the > selectors, the target resource type and the target resource super type. > > As recently discussed, we should remove the support of > Resource#getResourceSuperType which makes things much easier including > caching. > > But the above way has one major drawback: the cache (key) does not take > into account which scripts are available, it is based on the number of > possible combinations of extension and selectors for urls - which > usually is unlimited. For example, if only an html script exists for a > resource type (no scripts for specific selectors), requesting > foo.a.html, foo.b.html, foo.html result in three different cache entries > all pointing to the same. Which means with extensive use of selectors, > the cache becomes useless and ineffective. > > So rather caching the endless combinations, we should cache what is > available: for a resource type we can cache the combination of > extensions and selectors where scripts exist for. This is usually a very > small number. The cache can also know the resource type hierarchy and > then becomes really effective as it can simply traverse the cached > information top to bottom to find the script. With the right data > structures this should really be simple to implement. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
