mehdi houshmand | 9 Feb 17:08
Picon

URI Resolution

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


Gmane