Subject | Re: [IB-Architect] Re: Is it _really_ necessary to expose the location of the database file? |
---|---|
Author | Chris Heberle |
Post date | 2000-08-09T00:00:25Z |
Bill Karwin wrote:
How about storing the alias <=> path details in the isc4.gdb security
database? The server process already knows how to find that file, and
validate users. Why not look up alias details at the same time. This would
work in well with Sean's suggestion of trying "on-disk" first, and if that
fails, look up the alias in the security database and if a match is found,
try again with the new path. (This could even be recursive.)
This is cross-platform, requires no "external" access to another
file/registry/another process, and has the same security model as
adding/deleting users. It also does not "require" any change to existing
client code, unless someone wants to switch over to an alias system, with
all it's obvious benefits.
The "maintanance" of the aliases could be implemented similar to roles or
user maintenance, once again making use where possible of similar code.
This is not to squash Bill's idea of possibly having multiple locations for
looking up alias details - horses for courses, let the "end-user" decide
which method is appropriate for their situation.
Regards,
Chris Heberle
Intouch Technology
>Where to record the alias definitions:<snip>
>
>1) Windows registry.
>2) ibconfig.<snip>
>3) LDAP server.<snip>
How about storing the alias <=> path details in the isc4.gdb security
database? The server process already knows how to find that file, and
validate users. Why not look up alias details at the same time. This would
work in well with Sean's suggestion of trying "on-disk" first, and if that
fails, look up the alias in the security database and if a match is found,
try again with the new path. (This could even be recursive.)
This is cross-platform, requires no "external" access to another
file/registry/another process, and has the same security model as
adding/deleting users. It also does not "require" any change to existing
client code, unless someone wants to switch over to an alias system, with
all it's obvious benefits.
The "maintanance" of the aliases could be implemented similar to roles or
user maintenance, once again making use where possible of similar code.
This is not to squash Bill's idea of possibly having multiple locations for
looking up alias details - horses for courses, let the "end-user" decide
which method is appropriate for their situation.
Regards,
Chris Heberle
Intouch Technology