At 12:28 PM 4/27/00 -0400, dcalford wrote:

>
>Any change to the way we handle security needs to be both easy to maintain

(by

>the end user as well as the IB developers) and have applications beyond
>security itself. IB has become our favorite database because Jim saw beyond
>the obvious quick patch fixes used with locking and transaction handling
>became the IB standard. Any change made to IB needs to fully understand the
>implications, not just to the immediate need, but to the long term need of

the

>users. (and this means supporting platforms that do not support loadable
>modules)
>

Interbase should support basic account/password security (though I
think the role model needs expansion). More advanced authentication,
logging, threat detection, IP address based restrictions, account/IP
address affinity, and security event logging are currently unavailable
and unlikely to be implemented as part of the core product in the
near future, even assuming we were able to figure out the "right"
semantics.

A loadable module allows someone to write and distribute a more
capable security manager that plays with the mainstream product,
but doesn't require buy-in (or even source distribution) from the
entire community. It is the type of added value component that
we should encourage.

I don't expect most users will ever feel the urge to even consider
writing their own security manager -- if we build the hooks correctly,
they'll be able to acquire one appropriate to their needs. But
if they feel compelled to write one, I think it is completely
appropriate that it be written in a language for grownups.

All major platforms support dynamic linking. Although we
shouldn't preclude Interbase from running on stone-axe platforms,
I don't think architecture decisions should be based on the
assumption that the product needs to run off a card reader.

Jim Starkey