Sunday, July 16, 2006

Translating for developers

Hi, what follows are my personal thoughts after reading Dmitry Yemanov's comments to a great poll posted at Firebirdnews about the features people would like to see implemented.
1. SMP support is a clear winner (23% of votes) in the poll. And this is definitely one of the high priority tasks in the project. As you know, it was the major goal of the Vulcan development and its implementation is being currently tested. The public test versions will be available soon for those who's willing to test it in real-world scenarios. The final SMP implementation is targeted for the v3.0 release, as stated in our roadmap.
Well, since Intel and AMD are massively going for multicore architectures on the desktop and SMP servers are more and more common in datacenters I wouldn't place this in a whishlist, it's simply a must to stay current, no choice.
2. Better security (16%). It's not very clear what security issues are assumed here, but some fixes and improvements are already made and more ones are scheduled for the near future. In particular, you may expect embedded security, database encryption and trusted authentication quite soon.
Again, where are those developers hiding? It's good to see embedded security, database encryption and trusted auth, but isn't it time to add SSL encrypted communications between client and server? And, speaking of SSL, why not adding certificate based auth?
MySQL and PostgreSQL do support this from some time.
3. Cross-database queries (14%). This is a quite important feature that requires serious design investigation. Its implementation is not trivial, so it's not in the nearest schedule and hence it may require sponsorship to get a higher priority.
Ahhh, finally, the database is not a single, isolated, ivory tower!!! Now, why not putting up a temptative implementation much like MySQL's Federated storage engine? Something like a simple interface to a client library that dispatches calls to remote databases, which connection parameters are embedded in a view definition, I agree that it's not a clean implementation, but it could be a starter and raise people's attention.
4. Faster wire protocol (13%). Some improvements have already been made in this area (see previous blog records) and others are scheduled for the next versions.
Again, is it so hard to add what many other databases already have? Besides improvements to the protocol, which are extemely important for Firebird, please add zlib based compression, it shouldn't be that hard and it will put Firebird on pair with other OSS databases.
5. Server monitoring (8%). This feature is already being debugged and tested, so you may expect the core monitoring abilities quite soon.
Great!!! Now, please state it clear, can we hope in a v$sessions like view?

Apart from some sarchasm, I consider Firebird an excellent database developed by a highly motivated and competent group, but I was very surprised reading that post, because it seemed quite surprised by those requests, which are IMHO pretty standard.
Ok, enough for the rants now, have a nice day ;-)

Note: Mariuz (see post comments) added this rant to Firebirdnews and we can read some of Dmitry's comments about it, my favourite is that, yes v$session like views ARE coming!!!


mariuz said...

i have added this post on the firebirdnews
I hope you don't mind it :)

pabloj said...

Not at all, hope Dmitry wont feel too bad about my post and most of all didn't consider this Firebird bashing as you know I'm quite active in the Firebird forum at Devshed.

BTW: Nice to hear that v$session views are coming to Firebird (I read Dmitry's comments on Firebirdnews).