--- Comment #32 from Alex Watson <>  2009-04-13 
22:03:00 PST ---
Hi Jeremias,
Thanks for the pointers to the code base - that is a real help to my

I had considered the expiration idea for all images (rather than just for
missing images), but was not sure if it was the ideal solution. This solution
would be perfect for me (with my current problem), but it would not have helped
M.H. who originally raised this issue. It would depend upon how configurable
the expiration was and how expensive it was to re-fetch an image.

Can you explain your comments about the UriResolver being expensive in
high-volume applications? I didn't quite understand the part about HTTP and

I know that the built-in (default) UriResolver will create connections to HTTP
webservers or local FileSystems (etc) - and this can become expensive without
any caching strategies.

However, when a developer plugs-in their own UriResolver it can be as smart and
efficient as they like (and does not need to create external connections). We
have a global ResourceResolver class that implements the UriResolver interface.
This implements its own caching strategy (and caches fonts, nested XSLT,
imported XML as well as images). Our implementation primarily loads resources
from disk (file), but future extensions to our system could allow this to
generate XML, Images or even XSLT on the fly.

I guess that is why I would prefer a hook that will let me take care of (part
of) the caching solutuion.

Sorry I cannot help with the patch - we only specify "logical" resources within
our XSLT, they are all mapped to real resources via our UriResolver. We do not
use the Base parameter. For what it is worth, I think the patch looks OK to me
and may help some users - but it does not really address my concerns.



Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to