Re: [xslt] [ENHANCEMENT REQUEST] give URI Resolver hooks in PythonAPI access to per-invocation data

See comments below:

Daniel Veillard wrote:
> On Mon, Oct 14, 2002 at 01:08:13PM -0400, Craeg K Strong wrote:
>>I have finally gotten a chance to try out the new resolver hook:
>>         libxml2.setEntityLoader(myResolver)
>>This is a good start: I would like to propose an enhancement that
>>would give the resolver function access to per-invocation data.

>   I don't think I understand.
>   I don't see why you can't build the wrapper class around the 
> functionnality in your code around the existing API.
>   If you can make patches I can understand then I may apply them.
>   Well I won't understand it better there than here. First would be
> for me to really undertstand what you're after and if it's possible,
> Daniel

4Suite provides an InputSource class (quite similar to the InputSource
provided by Java's JAXP implementation) that provides the kind of functionality
that I seek.  A *very* high level overview is here:

The reason I want to be able to plug in an InputSource is this:

I want to specify new schemas, such as "URN" and have them get
resolved by a custom resolver routine that I provide.  The resolver
routine must *not* simply provide an alternative URL, rather the API
should return an InputSource.

For example, I could resolve a URN to a URL that happens to be
served by a webserver requiring authentication.
If I store away authentication information,
I can (in the custom resolver routine) grab the bits.  If, instead,
the API merely provides me with the ability to return a URL, I will
pass back a URL for which urlopen() will *fail* due to the lack of
proper authentication information.

My resolver could also have complex logic such as choosing between
a file:/// based URL and an http:// based URL depending on some
runtime configuration.

The python implementation in 4Suite is very simple, and I think it would
be pretty easy to whip up something similar for libxslt.  Let me know;
I could probably submit something within a week.  The main problem is
that I haven't coded in C in a *very* long time, so I could only provide
you with a Python version.  It would likely require significant adaptation
to get the capabilities into the C mainline and then provide Python wrappers.
Then again, that would probably be a piece of cake for you, no?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]