Jeremias,

I was looking into this, and it became abundantly clear that I don't really
know what you're trying to do with the java.xml.transform.URIResolver...
Would something like this be appropriate as an adapter between the two
interfaces? (The exception handling is pretty slap-dash). I don't have a
great deal of experience with these XML libraries other than the fairly
basic use-cases.

I appreciate that the DOMSource serialization would be performance costly,
but we already knew that...

Mehdi

On 30 July 2012 08:52, mehdi houshmand <med1...@gmail.com> wrote:

> Hi Jeremias,
>
> I'm sorry for the slow response, I will look at this when I get the chance
> to do so and get back to you. I would like to come to some sort of
> compromise on this, one where we're both happy with the acquisition of
> resources. Failing that, at least come to an agreement where neither of us
> are particularly happy but begrudgingly accept with a healthy amount of
> resentment ;)
>
> Mehdi
>
>
> On 26 July 2012 22:31, Jeremias Maerki <d...@jeremias-maerki.ch> wrote:
>
>> (responded on fop-dev)
>>
>>
>> Jeremias Maerki
>>
>>
>> On 26.07.2012 20:17:17 mehdi houshmand wrote:
>> > I appreciate that there are inconveniences, but if you're just looking
>> for
>> > backwards compatibility, the changes should be, for the most part,
>> fairly
>> > minor.
>> >
>> > I'm sorry we haven't been able to convince you of the benefits of the
>> > changes, that's on me as the lead on this. I'm not sure really what
>> else I
>> > can do to convince you, if you have specific concerns that we could
>> address
>> > then I'd be happy to see if we can come to some sort of compromise. You
>> > talk about a java.xml.transform.URIResolver interface, are there any
>> other
>> > things you'd like to see?
>> >
>> > On 26 July 2012 17:15, Jeremias Maerki <d...@jeremias-maerki.ch> wrote:
>> >
>> > > That's not quite true. That worked perfectly before by setting your
>> own
>> > > JAXP URIResolver. You could even resolve a URI to a DOMSource (or
>> > > SAXSource) containing an SVG image that you've dynamically built based
>> > > on some data (think charts). With the new approach, you have to
>> > > serialize that XML to a stream (buffered in memory or on disk) which
>> > > costs performance. Not a very common use case, I know, but we're
>> talking
>> > > possibilities that are going away with the API changes.
>> > >
>> > > Previously, you could use Apache XML Commons Resolver for XML catalog
>> > > functionality. Now you probably have to write an adapter from
>> > > URIResolver to ResourceResolver (haven't had time to try that, yet). A
>> > > convenience adapter is missing.
>> > >
>> > >
>> > > Jeremias Maerki
>> > >
>> > >
>> > > On 25.07.2012 22:25:52 Matthias Reischenbacher wrote:
>> > > <snip/>
>> > > > Btw... it's really nice that all data is loaded now through the new
>> URI
>> > > > resolver. In the near future I'd like to use a custom scheme (e.g.
>> > > > myscheme://imageid) in order to load images instead of using HTTP.
>> That
>> > > > wouldn't be possible without your change. So thanks!
>> > > <snip/>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> > > For additional commands, e-mail:
>> fop-users-h...@xmlgraphics.apache.org
>> > >
>> > >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>>
>>
>

Attachment: URIResolverAdapter.java
Description: Binary data

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Reply via email to