Subject | RE: [IB-Architect] Self-contained plug-ins |
---|---|
Author | Leyne, Sean |
Post date | 2000-05-02T17:56:26Z |
Jason,
I had the same though roaming around my head, but hadn't had the time to
completely verbalize it.
Personally, I prefer IBConfig.gdb.
Sean
-----Original Message-----
From: Jason Wharton [mailto:jwharton@...]
Sent: Tuesday, May 02, 2000 1:58 PM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Self-contained plug-ins
As an extension of my earlier idea, how about having these plug-ins a
part
of the server's configuration database rather than each application's
GDB
files?
This would solve the redundancy problem if there were a lot of GDB's on
an
individual machine and still enable a certain amount of cross platform
ease
of use because this server configuration database could be replicated
along
with transporting the GDB file to another server.
The application GDB's would then be configured to access the server's
configuration for the plug-in rather than an external OS dependant
resource
like a .DLL or .so module directly. Thus, a GDB could be setup to access
a
certain module in a platform independant way and the server would be
setup
to alias and abstract the implementation of the module.
Then, it would be a matter of moving the GDB to another machine and
installing the plug-ins into the server's configuration and you would be
ready to roll... Being able to replicate the server's config items from
one
server to another would be icing on the cake...
Let's name the server configuration file ISC7.GDB instead of ISC4.GDB...
I think the ISC7.GDB configuration database just needs to have more
goodies
added to it including a system of managing plug-ins ( eg. security,
UDF's,
external data access ), aliases (meaning GDB locations too),
administrators
privilages (including credentials to prevent copying of this ISC4.GDB
file
to another machine and hacking it), etc.
This particular file may ought to be stored in an encrypted format so
that
it cannot be viewed in a hex editor and deciphered. Afterall, this would
most likely be a center of attention by a hacker looking for what inf.
they
need to compromize a system.
All this talk about ASCII, Registry, XML, etc. for storing configuration
information seems pointless since we already have an excellent medium to
store information in. GDB! InterBase has already got that part right
with
ISC4.GDB.
Am I going overboard here or is there some real feasibility to these
extensions?
My appologies to all that like a nice little bare bones DB engine
because my
agenda is to get InterBase into the Enterprise realm of things...
Regards,
Jason Wharton
InterBase Developer Initiative
jwharton@...
InterBase will be the database of the new millennium.
------------------------------------------------------------------------
Join Garden.com's affiliate program and enjoy numerous benefits.
To learn more click here:
http://click.egroups.com/1/2753/3/_/830676/_/957289540/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
I had the same though roaming around my head, but hadn't had the time to
completely verbalize it.
Personally, I prefer IBConfig.gdb.
Sean
-----Original Message-----
From: Jason Wharton [mailto:jwharton@...]
Sent: Tuesday, May 02, 2000 1:58 PM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Self-contained plug-ins
>Just a random thought that might or might not spark some betterideas...
As an extension of my earlier idea, how about having these plug-ins a
part
of the server's configuration database rather than each application's
GDB
files?
This would solve the redundancy problem if there were a lot of GDB's on
an
individual machine and still enable a certain amount of cross platform
ease
of use because this server configuration database could be replicated
along
with transporting the GDB file to another server.
The application GDB's would then be configured to access the server's
configuration for the plug-in rather than an external OS dependant
resource
like a .DLL or .so module directly. Thus, a GDB could be setup to access
a
certain module in a platform independant way and the server would be
setup
to alias and abstract the implementation of the module.
Then, it would be a matter of moving the GDB to another machine and
installing the plug-ins into the server's configuration and you would be
ready to roll... Being able to replicate the server's config items from
one
server to another would be icing on the cake...
Let's name the server configuration file ISC7.GDB instead of ISC4.GDB...
I think the ISC7.GDB configuration database just needs to have more
goodies
added to it including a system of managing plug-ins ( eg. security,
UDF's,
external data access ), aliases (meaning GDB locations too),
administrators
privilages (including credentials to prevent copying of this ISC4.GDB
file
to another machine and hacking it), etc.
This particular file may ought to be stored in an encrypted format so
that
it cannot be viewed in a hex editor and deciphered. Afterall, this would
most likely be a center of attention by a hacker looking for what inf.
they
need to compromize a system.
All this talk about ASCII, Registry, XML, etc. for storing configuration
information seems pointless since we already have an excellent medium to
store information in. GDB! InterBase has already got that part right
with
ISC4.GDB.
Am I going overboard here or is there some real feasibility to these
extensions?
My appologies to all that like a nice little bare bones DB engine
because my
agenda is to get InterBase into the Enterprise realm of things...
Regards,
Jason Wharton
InterBase Developer Initiative
jwharton@...
InterBase will be the database of the new millennium.
------------------------------------------------------------------------
Join Garden.com's affiliate program and enjoy numerous benefits.
To learn more click here:
http://click.egroups.com/1/2753/3/_/830676/_/957289540/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com