Re: [Firebird-devel] RFC: Adding a cryptographic library for use in firebird

[Mark O'D. <mar...@gm...>]

Hi Adriano

Thanks a few clarifications:

On Mon, Nov 24, 2008 at 2:10 AM, Adriano dos Santos Fernandes
<adr...@uo...> wrote:
> Mark O'Donohue wrote:
>> b) For encrypt(x) it is easy, the return type is based on input type,
>> so text returns text (although unsigned char, charset none, but could
>> be octets), and blob returns blob.
>>
> I think octets is more correct.

I agree, but my proof of concept doesnt have them yet.

>>
> See makeRevert:
>    if (value->isBlob())
>        *result = *value;
>    else
>        result->makeVarying(value->getStringLength(), value->getTextType());
>

That is, roughly, what I have,

But If I want to throw an exception during prepare rather than
execute, where is the best place to do that?

I only accept text or blob, currently I throw from evlXXX the only
other places to move that check to would seem to be the setParamsXXX
and makeXXXX functions.   So to confirm,  are you saying its best I
should let it other data types pass through the makeXXX and then throw
an exception in the evlEncrypt, as I do currently - eg:?

    if value.isBlob()
    else if value.isText()
    else
       throw exception

The same applies if I want to move of the excepton thrown for
"cypherName not found"  to the prepare, as you suggested,  where
should I move it to ? (currently it throws in evlXXXX)?


And from before:
>> I will change this in SysFunctions.cpp, and also rework the
>> makeXXX, evlXXX, and setParmsXXX functions as methods of classes.
>
>Oh no, please. Note that some makeXXX, setParamsXXX and even evlXXX are
>shared. Also, it doesn't sound ok for me a lot of classes (one for each
>function) with two or three methods.

Just curious why you don't like this, I would have thought a
structure, with a bunch of pointer to functions, and many different
implementations all created with a macro, was a classic interface and
many implementations.

True there is no performance gain, but it fits an OO structure better.
 The shared methods I don't really see as a problem, probably a base
class with the core shared ones in there.

Cheers - Mark


PS: Thanks for unknown that explains what that was about :-)