Robert F. Tulloch wrote:

> Are any of you suggesting making changes to IB that would render it
> incompatible with app being written right now?

I think we will get lots of, maybe even "wild", suggestion, but rest assured
that enough of us are aware that compatibility is vital.

> An example: I am checking in reg to see if IB is installed, if it is
> running and if not, start it with Guardian. I saw some comments about
> getting rid of Guardian.

This is a beautiful thought, I think I was the one that brought it up by
some bugfixes. :-)
However, fear not, Guardian will be along for quite a while yet. We try to
fix bugs, but we're not *that* fast. :-) And even if we were, Guardian could
possibly be the final "safeguard" that still proves to be needed. Even if it
proves to be redundant, it really doesn't hurt *that* much having it around
"just in case".

However, you will probably *not* be able to do this exactly the same way in
the future. The reason for this is that I think you are looking inside a
"Borland" branch in the registry (note: this is a Win32 thingie, also called
"the ini-file from hell"). If that's so, you *will* have to change this
code. There is IMO no way an Open Source project should (or possibly even
legally *could*) use the Borland branch in the registry.

May I suggest an alternative implementation? Use FindWindow() and look for
the class name "IB_Guard". That's the window class name for the IBGuard, and
*that* will not change. If not found, try to start it by CreateProcess(). If
that fails, assume it's not installed and ask for user intervention.

> What kind of control and by whom over what will be done with IB since
> it is open source?

None and all. Quite an exhaustive and confusing answer, eh?
It is now a community effort. There is no "executive entity", there are only
votes. It's a bit like the difference between monarchy (or even communism)
and democracy.

There are quite a few people taking part in this, and their numbers is
getting greater by the day. Some of these are long-time IB users, some are,
like myself, new to IB but oldtimers in other areas, some are even persons
that have worked on IB in the past and knows it "from the inside". The
control is done by a responsible and caring community, and the "what will be
done" will be by majority decisions in the cases it needs voting.

> I would hope that "improvements" are restricted to necessary fixes
> and the philosophy of "If it ain't broke, don't fix it" would prevail.

That would depend on what level your question is directed at. If your
concerns are about client API and/or its current SQL behaviour, this will
stay. We're not doing this "this just for the fun of it" and "redesign
because we don't like it". Long term stability is a goal, and that includes
current installations.

So, rest assured that you will be able to use IB also tomorrow, perhaps
under another name, but it will still be the DB to depend upon.

/Mike - A Firebird project admin

http://sourceforge.net/projects/firebird