Hi Jeremias,
I'll add my comments inline:
<snip/>
>
> First, I'd like to stress that I'm not putting out a veto here. I'm
> just trying to take the position of an advocate to the FOP users who
> might not all follow the development closely.
>
Yeah, I/we do appreciate your concerns, it's important for any body of work
to stand up to scrutiny. We need your (both personal and the collective
"your") experience and expertise to critique our work not only so that we
maintain the high quality of FOP, but to improve ourselves as developers.
>
> Back on the technical side: A JAXP TransformerFactory is just as mutable
> as the FopFactory, but only if it's handled wrongly by the developer of
> the client code. In the application I'm currently working on, the
> FopFactory is created once based on the configuration and registered as
> an OSGi service. All client code using the FopFactory (service) is
> written as if the FopFactory is immutable. Yes, I'm counting on the
> participants to play nice although I can still proxy the FopFactory if
> need be. And my application is also targeted to be deployable in the
> cloud (I hate that wishy-washy term) and already works with zero access
> to the local file system.
>
I ask you this; how are we defining work? The caveats we imply and
assumptions we make aren't trivial. Are we talking about just producing
plain vanilla documents with no custom fonts and no images? Sure, works
like a dream. Or are we talking about very strict I/O such that no user can
either intentionally/unintentionally access someone else's resources under
ANY circumstances? Well... No. I'm just not confident that it would be
possible to guarantee that level of security.
Having immutability in the FopFactory allows us to make assertions, it
prevents "if (x == null) { x = <default value> }" all over the shop.
>
> So to be frank, I still see squeeky clean, best practice design (which
> is in itself nothing but good) being put before continuity (or API
> stability) without an absolute need for an API break to enable
> "cloud-compatibility". And I personally weigh API stability higher than
> design principles. The world isn't perfect. However, I see no problem
> improving the URI resolution the way you propose it as long as it is
> done in a backwards-compatible way. Again, no veto, just my opinion. I
> might be the only one here who sees it that way.
>
> <snip/>
Well again, we're breaking the API anyways! Because FopFactory relies on
I/O for setup (the font-cache, and the fop-conf if it is used, the latter
I'll discuss in more detail), we need both a base-URI and a URI resolver
when the FopFactory is instantiated. There's not a lot we can do about
that, we can't have FOP accessing the "user.dir" in the cloud. There is an
argument to be made that we disallow fonts-caching, but then we're not
solving the problem, we're de-scoping.
As for the fop-conf, if it is used, keeping the old mechanism, a client
would have to do the following:
FopFactory f = FopFactory.newInstance();
f.setUriResolver(...);
f.setUserConfig(...);
If they didn't set the URI resolver *before* setting the user config, then
they're going to see different behaviour. Also if the did this:
FopFactory f = FopFactory.newInstance();
f.setUriResolver(...);
f.setUserConfig(...);
f.setUriResolver(...); <-- different URIResolver used here!
then they're gonna see even more unusual behaviour, since there's a
disparity between the URIResolver used set to configure the FopFactory and
that used to configure the PrintRenderers. A friend of mine once said to me
"you can use all your wit to make things idiot-proof and an idiot will come
along and out-smart you", and I very much agree you can't protect against
every quirky use-case. But the above just doesn't seem right to me. If an
object is used for configuring and initializing a class, it should be in
the constructor.
Thanks for your patience Jeremias, it really is appreciated,
Mehdi
