t_j_haynes wrote:

>Firebird's biggest problem today is the lack of a viable Windows
>server. In the real world everyone runs multiple CPU servers, even
>more so with hyperthreading and dual-core chips. Unfortunately the
>Superserver doesn't handle multiple CPUs and the Classic server is
>apparently not properly tested on Windows. This rules Firebird out
>of most 'real' use on Windows. A multithreaded multi-CPU server
>would be the ideal answer, but this isn't scheduled until V3.0
>(Vulcan). A reliable Classic server today would at least allow those
>thinking about adopting Firebird to make a start.
>
>

Vulcan is currently schedule for first product release by the end of
December. It may not have 100% of features new to V2, but we expect to
have the bugfixes.

>Next most urgent issue is the safety of information. A good backup
>(including incremental) is critical, and I gather that this is being
>addressed for version 2.0. Another not uncommon requirement is for
>simple whole-database replication, but sadly Firebird's shadow
>databases sadly fall just short of being a truly brilliant
>distinguishing feature and trigger based replication mechanisms are
>comparatively lousy.
>
>

What exactly do you want? Are you looking for physical replication
(which is what shadows are), logical replication, or just something that
supports hot rollover? Could you be specific about your objects to
IBReplicator and other (potention) trigger based replication schemes?

>Third is the lack of documentation. This is largely addressed by
>buying the book, but the online stuff is a mess - a mix of current
>and old Interbase stuff. It really needs to be current and Firebird
>branded.
>
>

Start by the fixing the economics, and the documentation will follow.
The problem isn't specific to Firebird -- have you ever tried to write
an Apache 2.0 modules from their documentation?

>Last, but not least is the lack of a standard graphical
>administrative interface. This doesn't worry me, but some of these
>youngsters today can only function in a point-and-click world. A
>problem is that there are several GUI tools available, causing
>confusion among users who just want to install the standard package
>and have it just work 'out of the box'.
>
>

Again, an economic issue. There are a number of companies that make a
business of selling administration interfaces that add significant value
to Firebird. Should we try to put them out of business?

We've been talking recently of an administration backend with a
socket/XML interface to could be used by a variety of GUI (and command
line) front ends and a sample GUI (Windows because people who insist we
use other GUIs don't volunteer). Does this meet your needs?


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376