9 Feb 17:08
URI Resolution
mehdi houshmand <med1985 <at> gmail.com>
2012-02-09 16:08:51 GMT
2012-02-09 16:08:51 GMT
Hi, As I've said previously, I've been looking at unifying URI resolution, I've looked at a lot of the code regarding this and from what I can see FOP uses file access for the following types of files: 1) Input/Output files - by that I mean FO and output, both of which are many-to-many 2) Resources - fonts, images, hyphenation-patterns, colour profiles etc 3) AFP resource file - arguably could be an Output type, but not handled in the same way 4) Scratch files - used for caching and optimize-resources etc I think a lot of the URI differentiation can be done within the URI itself, so we can use just an interface with two methods: InputStream getInputStream(URI); OutputStream getOutputStream(URI); This interface will be bound to the FOUserAgent and a setter on the user agent will allow clients to define their own implementation. I think we can avoid having "Source getSource(URI)" in the API by using converting them into a javax.xml.transform.Source when necessary with "new StreamSource(InputStream)" (same for OutputStream->StreamResult). The only issue here is that Source objects also hold their URI, so if the source object is created one place, and the URI is read in another, that could be problematic. They're passed around a lot, so it's not so easy to chase them all the way through the rabbit hole. There are, however, a few more unknowns most relating to images, because I haven't seen how these are used in xgc-commons or batik. But no doubt we're going to have to make API changes to them anyway so we might as well cross that bridge when we come to it. I think we do this incrementally though, since it's going to touch so many areas of code, I think the best idea is to do this in steps. I will create a branch for Apache so each changes are made publicly available, so do keep an eye on it, since the changes will have quite far reaching effects. In terms of the nuts and bolts, I think the biggest difficulties here are to do with clean up. There is a disappointing amount of very similar but not quite the same code which is going to be tricksy. In terms of worries about regressions or the like, I will do my best to minimize any impact, however, there are quite a few different URI resolution methodologies. If say you're using a custom FontResolver and a custom FOUriResolver, then there will be an impact. So I think the best course of action is to start with the fonts packages, since it's probably the area of code I'm most comfortable with, replacing the various URI resolution methods with a single one. Thoughts? Mehdi
RSS Feed