Scott Cantor wrote:
> Most of the 64-bit warnings are probably from Xerces, but if you have
> anything you can fix there, it would also be appreciated. I'm getting more
> demand for 64-bit builds lately.
Hmm. Don't have a 64 bit system to do a build on. Must try and see if
I can track something down.
> That's part of it, particularly making sure things are as stateless as
> possible. Right now, I have this extra XSECProvider thing I'm lugging around
> as a (nearly) global variable just to create and release signatures, but it
> doesn't seem to add any actual value.
The original idea was that it could re-use objects rather than
completely deleting and re-allocating all the time. That was the idea -
but I haven't yet had time to make it work.
The other part was as a message factory - I'm trying to hide the
implementation from the user. If you look at the XKMS classes they are
completely interface only now. That's where I want the Signature
classes to be as well. The message factory side of it could potentially
be done using static methods, but I wanted to avoid that to keep thread
handling simpler in complex applications. (Mind you, if we passed
ownership straight to the caller then thread issues are pretty much
non-existant - it's only an issue if we continue to keep a memory of all
signatures we have allocated.)
>
> I've also been looking ahead to the encryption stuff, and I'm not sure I
> understand the implications of the XSECEnv yet. I'm generally sensitive to
> lugging around other objects I need to manage because of the hairiness of
> DOM management in Xerces-C.
>
> Anyway, I don't have much to suggest yet, and it wouldn't be on this
> timeline.
Where are you seeing an XSECEnv? That should be completely hidden
unless you are manipulating the implementation classes directly! If you
are having to manipulate the Env class directly for normal operations
then I have a bug somewhere. For encryption the only things you should
need are the Cipher and provider classes.
I need the env class within the implementation classes to link the
various parts of a Cipher object together. As an example, if we need to
create a CipherReference, it needs to be a part of the document for the
EncryptedType. Similarly, I needed a place to store information about
namespace qnames without having to look at the owning object.
I started out by always going back to the parent class, but that gets
really ugly in a few places (some objects can have different parent
classes in the message sense) and I found the easiest way to handle
things was to have an environment object that exists as a part of a
particular message. There is a super object from which all the others
are derived during message creation (to keep consistent qnames and the
like), but again you shouldn't have to worry about it. Generally only
the EncryptedType has an actual env object - all the sub-objects have a
link only.
Really it just encapsulates all the information that is common for all
the objects that make up an EncryptedType object. There is probably a
nicer way to do it, but I couldn't see it :<.
Cheers,
Berin
