Leyne, Sean wrote:

>Why do you want to relate user authentication issues with file
>encryption? They seem to be "apples and oranges".
>
>Or are you using "security plugin" as a term under which you are
>grouping families of functions/hooks which can be handed off to external
>functions?
>
>
>

I think a security plugin (or chained plugins) should define all
security policies for the database engine. Authentication is one part,
file encryption is another, attack response is a third, etc. The way I
would like to see the security plugin defined is similar to the
SubSystem class used by Dispatch and all providers -- we define a class,
call it it DatabaseSecurity, that defines virtual methods and default
implementations for all security hooks we think we need. A plugin that
only handles authentication doesn't need to worry about the rest of the
stuff.

> <>
> Shouldn't the plug-ins only register for functions/hooks which they want
> to 'intercept'? Much like a callback can be registered and then
> called/invoked as required but if none are define nothing is called.
>

Sean, we've gone through all the fuss and bother to switch over to C++.
Please, couldn't we give object technology a try?


[Non-text portions of this message have been removed]