xmlsec-c question about XSECEnv

[Scott Cantor <ca...@osu.edu>]

I'm starting to incoporate a few pieces of the XML Encryption classes into
some of my project, and I had a question about the XSECEnv class,
specifically about the DOMDocument parameter in the c'tor, and how to use
this class.

Is this object supposed to be created per XML instance being manipulated? It
seems like more of a global settings object that would be static and common
across the library.

I looked at the code, and I can see that right now there wouldn't be much
harm if I passed NULL in, but obviously I can't depend on that behavior.

-- Scott

Re: xmlsec-c question about XSECEnv

[Berin Lautenbach <be...@wingsofhermes.org>]

In an ideal world you shouldn't have to touch XSECEnv at all.  The idea 
is a way to pass information between the various library components 
about a particular piece of XML.  As an example, the XENCCipher class 
"owns" an instance of XSECEnv.  It then passes it to all the other XENC 
classes that it uses to actually build an encrypted (or decrypted) 
piecce of XML.

So the class is created per XML instance - but all the objects that 
exist around that instance should have pointers to that single instance.

My read of below is that you are lifting bits of code from the library 
to use in your own stuff rather than actually calling the library 
through the API?  XSECEnv is supposed to be hidden from normal use, so 
I'd be concerned if there is somewhere you have to manipulate it for 
normal use of the library.

Cheers,
	Berin

Scott Cantor wrote:

> I'm starting to incoporate a few pieces of the XML Encryption classes into
> some of my project, and I had a question about the XSECEnv class,
> specifically about the DOMDocument parameter in the c'tor, and how to use
> this class.
> 
> Is this object supposed to be created per XML instance being manipulated? It
> seems like more of a global settings object that would be static and common
> across the library.
> 
> I looked at the code, and I can see that right now there wouldn't be much
> harm if I passed NULL in, but obviously I can't depend on that behavior.
> 
> -- Scott
> 
> 
>