We've got a major architectural problem. The functions isc_add_user and
isc_delete_user violate the architecture and can't be implemented.

The problem with these functions is that they pass security information
as a C structure which is non-portable, unstable, and can't be handled
by plumbing layers. The functions work in current versions only because
the current system is built as a monolithic monster.

All over complex structures are built as encoded packets (information,
blr, sql, dpb, tbp, bpb, etc) passed with length and address so the
plumbing layers can transmit the data without understanding it, and the
stuff means the same on all systems.

I suggest that somebody resign those calls with clumplet structures
modeled on the other half dozen or more systems that do parallel things,
and produce the smallest possible mapping function from the current
scheme into an architecturally supportable call.

It would make a great deal of sense to have a single call to handle all
security functions -- create, delete, update -- that could be passed in
it's entirety to a plugable security module. This would leave the
question of semantics as a matter between the client and the security
module leaving everything else as transparent transmission layers.

I need a solution for Vulcan right away, so I'll take a first crack at
both the API and plugable security manager, but it's going to be a
superficial quickie. There are undoubtable people who care about the
details a great deal more than me, so the sooner somebody grabs the ball
and runs with it, the happier we'll all be.