Subject | Re: [Firebird-devel] Conflagration Files |
---|---|
Author | Jim Starkey |
Post date | 2004-01-06T16:04:47Z |
Mark O'Donohue wrote:
seriously. And three is a very contradictory number. A three sided
polygon is a paragon of stability. An intimate relationship of three
people is the essence of instability.
Programmers need to count, zero, one, infinity...
There may be three today, next week there'll be 14. When people
reasonize how easily and cleanly they can drop specialized data
management subsystems, especially ones that front end to other systems,
you can expect the number to mushroom.
works for all cases. A modest goal. I want a configuration mechanism
that can be extended to model organizations, as all software should. I
want the ideas of system managers and dbas to whither and die. I want
people to have control over their data and the right to delegate that
control for the common good. I want the beast to do the right thing out
of the box and be mallable when folks learn enough to make intelligent
decisions on customization. I want a database system as nice as my dog
that doesn't wake me up before the clock goes off.
Clear enough?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Mark, three isn't a number that mother nature intended to take
> Hi Jim
>
>
> As I see it from what you've outlined previously, ignoring wire
> protocols, you are looking at three access modes:
seriously. And three is a very contradictory number. A three sided
polygon is a paragon of stability. An intimate relationship of three
people is the essence of instability.
Programmers need to count, zero, one, infinity...
There may be three today, next week there'll be 14. When people
reasonize how easily and cleanly they can drop specialized data
management subsystems, especially ones that front end to other systems,
you can expect the number to mushroom.
>I want consistent, extensible, layered configuration management that
> 1. embeded access
> 2. remote server access
> 3. local server access
>
> Previously with suid, super vs classic, embeded mode, and servers
> running as root, the "local server access" did a variety of things,
> some good some bad.
>
> I was thinking we remove it altogether and just leave the client with
> the choice (though a Y value) of either direct 'embeded' access or
> secure 'server' access. But you seem to have some other ideas for
> 'local server access', do you mind explaining what your thinking is?
works for all cases. A modest goal. I want a configuration mechanism
that can be extended to model organizations, as all software should. I
want the ideas of system managers and dbas to whither and die. I want
people to have control over their data and the right to delegate that
control for the common good. I want the beast to do the right thing out
of the box and be mallable when folks learn enough to make intelligent
decisions on customization. I want a database system as nice as my dog
that doesn't wake me up before the clock goes off.
Clear enough?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376