Apache FOP development

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

(Continue reading)

headers

Jeremias Maerki | 21 Feb 00:16

Re: URI Resolution

Hi Mehdi,

I'm on hiatus from working on FOP due to various experiences and the
direction the project has taken policy-wise in the last few months, but
I can't help but chime in here in fear of this taking a direction I feel
is not in the interest of the project (i.e. mainly of its users). In
this post, I'd like to address points from both this thread and the wiki
page: http://wiki.apache.org/xmlgraphics-fop/URIResolution

First, I would like to suggest you start with listing relevant code
portions on the wiki before anything else. Where is what? And what's the
problem with each case? Right now there are only a few vague pointers
and an underlying unhappiness with the various approaches.

javax.xml.transform.URIResolver is the standard interface for URI
resolution in the JAXP world which is the most important Java API for
XML processing. The SAX EntityResolver is basically its predecessor. The
most popular implementation of the two interfaces is probably Apache XML
Commons Resolver, an implementation of the XML Catalog standard. While
URIResolver uses Strings rather than URI instances (URIResolver
predating java.net.URI), it has served me very well to date. In a system
I'm currently building, URIs and URI resolvers (or "resource resolvers"
if you want to generalize) have introduced a huge flexibility in how
resources can be resolved and accessed (be that XML or not).

Granted, URIResolver has been designed for JAXP, an XML API, but we're
not only loading XML but other resources like fonts, images, hyphenation
patterns, configuration files etc., too, where an InputStream is usually
sufficient. Using a URIResolver for non-XML resources introduces some
inconvenience or complexity but OTOH allows to re-use of URIResolvers

(Continue reading)

headers

Chris Bowditch | 21 Feb 11:48

Re: URI Resolution

On 20/02/2012 23:16, Jeremias Maerki wrote:
> Hi Mehdi,

Hi Jeremias,

Thanks very much for taking the time to write such a long and 
comprehensive e-mail. There is some useful feedback below and I've asked 
Mehdi to take a closer look at the details. Just one question from me at 
the moment. What are the policy decisions that you think the project is 
taking that you don't agree with? Sorry but I hate generic statements 
like that, if you are going to say something then you ought to give the 
details.

Thanks,

Chris

>
> I'm on hiatus from working on FOP due to various experiences and the
> direction the project has taken policy-wise in the last few months, but
> I can't help but chime in here in fear of this taking a direction I feel
> is not in the interest of the project (i.e. mainly of its users). In
> this post, I'd like to address points from both this thread and the wiki
> page: http://wiki.apache.org/xmlgraphics-fop/URIResolution
>
> First, I would like to suggest you start with listing relevant code
> portions on the wiki before anything else. Where is what? And what's the
> problem with each case? Right now there are only a few vague pointers
> and an underlying unhappiness with the various approaches.
>

(Continue reading)

headers

mehdi houshmand | 21 Feb 15:39

Re: URI Resolution

Hi Jeremias, I'll address your concerns inline:

<snip/>
> First, I would like to suggest you start with listing relevant code
> portions on the wiki before anything else. Where is what? And what's the
> problem with each case? Right now there are only a few vague pointers
> and an underlying unhappiness with the various approaches.

My apologies for any lack of clarity on my part, the issues around URI
resolution are in no way due to any unhappiness on my part. Infact,
rather frustratingly, great effort has been made to have fallback
mechanisms to  allow ambiguity from the user (which I'm sure we all
know happens all too often). However, as far as I can tell,  URI
resolution is a single problem, and as such, should have a single
solution. Now, I do appreciate there are nuances involved, but
allowing for them (which I'll discuss later) there should be a single
URI resolution mechanism.

The problem I'm trying to tackle here is how do we sandbox FOPs file
access? With the current implementation, that isn't possible. There's
too much contingency i.e. if this resolved URI doesn't exist, check
this one. As I've said, in the cloud, we have to be very strict, we
cannot allow one user to gain access (intentionally or otherwise) to
another users data.

<snip/>

> I think it can be useful to think about simplifying the use of
> URIResolver to new interface for resource resolution where only
> InputStreams are required. IMO, it should then still be possible to use

(Continue reading)