Firebird News

[See remaining text…] 

Ann: I plan to make my best efforts for both companies and build the reputation of Open Source Databases and Open Source as a better model for doing business. The database market is huge and the availability of high quality open source databases is accelerating the growth. There’s plenty of room for Firebird and MySQL and PostgreSQL and Ingres and CloudScape and SQLite and all the rest. In specific, the differences in licenses and configurations of MySQL and Firebird mean that they appeal to different segments of the market.

FBNews: Can you tell us if Netfrastructure will be open sourced by MySQL? If don’t so, what do you think is the currently role of Netfrastructure in the actual MySQL AB business?

Ann: At the moment, no one knows. MySQL hired Jim for his mind and his track record, not for the 17″ stack of listings that are Netfrastructure.

FBNews: What is Jim currently job in MySQL AB? Will he only work in Netfrastructure improvements or is he going to participate in MySQL database development?

Ann: He’s also a senior architect.

FBNews: Do you think MySQL will use Jim’s expertise to create its own full featured MySQL engine, considering that now Oracle has InnoDB?

Ann: Certainly, MySQL recognize the benefits of a transactional backend. They hired Jim because he designed and implemented three transactional engines: Rdb/ELN, InterBase and the Netfrastructure engine called JSTar.

FBNews: Can you explain to the common users what are the major conceptual and architecture differences between Netfrastructure and Firebird?

Ann: Sure.

First, Firebird started as a C program and is only gradually adopting serious object discipline. All of Netfrastructure is designed and build as objects. The code looks completely different.

Second, Firebird relies on careful write directly to the database to maintain on-disk consistency at every point in its operation, eliminating the need for a recovery process.JStar writes data changes to a log file – logged changes are gradually propagated to the database. After a crash, a recovery process brings the database to a consistent state before restart.

Third, Firebird is multi-generational on disk. JStar is multi-generational in memory, but only the most recent committed data is stored on disk. This reduces the cost of garbage collection and greatly increases the memory usage.

Fourth, Firebird has a tiny memory footprint for a relational database. Data is cached only as it occurs on pages. JStar maintains an in-memory record cache with version chains.

FBNews: Many times you are referenced by the community as the InterBase/Firebird “mother”. With the recent events, can we expect that Firebird is getting orphan?

Ann: Firebird has dozens of parents – Paul, Dmitry, Arno, Helen … It can never be an orphan again. And I’m not leaving. I may cut down on consulting so I can be more annoying on the lists to make up for Jim’s cutting back there.

FBNews: In your vision, what are the benefits and loss (if any) to Firebird project with all the recent moves?

Ann: Not much of either, frankly. This really isn’t about Firebird, it’s about Netfrastructure and Jim. The lists will hear less from Jim, but he’s promised to lurk on architecture where he has most to contribute. His work on Vulcan is done except for some bug fixing that’s included in everyone’s plans. The integration will go more smoothly without him, I suspect.

« Hide it