C++ feature request

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

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

Re: C++ feature request

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

Scott Cantor wrote:
>>What about another three methods on XENCCipher
>>
>>DOMNode * encryptElementDetached(.....)
>>DOMNode * encryptElementContentDetached(....)
>>DOMNode * decryptElementDetached(......)
>>

These have been checked into svn - very simple but seem to work OK.

Cheers,
	Berin

RE: C++ feature request

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

> 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.

Either new methods or flags (with a default parameter) are fine by me. The
latter would be API compatible as well.

> 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.

Right.

> How does that sound?

It sounds perfect, thanks.

-- Scott

Re: C++ feature request

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

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
> 
> 
>