Actually makes good sense, and shouldn't be a big deal to do. It's just
a matter of breaking the existing functions in two.
What about another three methods on XENCCipher
DOMNode * encryptElementDetached(.....)
DOMNode * encryptElementContentDetached(....)
DOMNode * decryptElementDetached(......)
The result is passed back as a DOMNode because the result of a decrypt
might be a Document Fragment or an element.
The returned DOM structures would be owned by the original document, but
detached from that document, and nothing in the original document will
have been modified.
How does that sound?
Cheers,
Berin
Scott Cantor wrote:
> Probably too late to be considered for 1.3, but I thought I'd ask anyway...
>
> I'm seeing an upcoming problem in that the Encryption/Decryption calls
> assume that I want to replace the nodes being fed in with the result (in
> either direction).
>
> In my particular library, this will cause some problems because of the
> objects I've got wrapped around the DOM and I'd prefer to manage the node
> replacement myself when I'm ready to do it.
>
> It occurs to me that I could maybe work around it if the old nodes aren't
> explicitly wrecked or disposed of by the API calls, but I haven't tried it
> yet, and it would be simpler to be able to signal that somehow. Is that
> possible?
>
> -- Scott
>
>
>
