Friday was my last day at Sun Microsystems, and today is the first day at my new job (location coming soon). I’ve had a great time at Sun, and thank them for all the opportunities given to me there. I’ll be doing mostly the same work at the new gig, working on projects like Drizzle, but with a slightly different focus. For the most part my day-to-day won’t change much.

Right now I’m focusing on libdrizzle again and am implementing the prepared statement API, cleaning up the MySQL protocol support a little, and also implementing the new Drizzle client/server protocol. I’ll continue to work on Gearman as well, especially where it is relevant to Drizzle. I also need to start blogging again with specific topics in the projects I’m working on, I’ve been fairly quiet lately.

I’ll be in New Zealand next week at Linux Conf AU (yes, it’s not in AU this year). I have a …

Friday was my last day working for Sun Microsystems, which means it was also the end of the job that started when I was hired by MySQL, Inc a little over four years ago. For those of you who didn't know me before that, it should be noted that the other than periods of time when I have started companies and worked for myself, the next longest I've ever been with one company was 10 months. I mention that as one of the few quantifiable metrics I could cite in describing what a wonderful experience it has been to work for MySQL and then Sun. The people I've worked with have been nothing short of stellar.

I will be continuing my work as a core Drizzle developer, so this blog post notwithstanding, I doubt most people will notice the change. The only real outward difference I can think of is that now that I'm not a Sun employee, I am free to comment on the merger and on what some people see as the need to save MySQL from Oracle. I don't know if I …

#define READ_ALL           1       /* openfrm: Read all parameters */
#define EXTRA_RECORD            8       /* Reservera plats f|r extra record */

and later on….

  if (prgflag & (READ_ALL+EXTRA_RECORD))
    records++;

Feel free to think about that for a second.

(I have an urge to add this to questions asked in a job interview…)

Yesterday, I was working on a survey that Selena Deckelmann put together for open source databases. She will be presenting the results at Linux.conf.au this month.

One of the questions on the survey was this:

How would you describe your development process?

followed by these answer choices:

• Individuals request features
• Large/small group empowered to make decisions
• Benevolent dictator
• Other, please specify:____________

I thought a bit about the question and then answered the following in the “Other, please specify:” area:

Bit of a mix between all three above.

The more I think about it, the more I really do feel …

I've got some code in lp:drizzle/staging right now that's on its way (barring major catastrophes) to trunk. It's not code that does anything sexy as far as the actual running server is concerned. It's a code cleanup branch.

Anyway - short story being - everything from mysys and mystrings that is actually part of public APIs has been moved into drizzled/ proper. Everything else has been moved into drizzled/internal. None of the headers from drizzled/internal are installed... so none of the headers in drizzled/ should be using any of them. Combine this with the past week's removal of both server_includes.h and global.h, and we're getting pretty close to having fully consumable headers.

Which brings me to:

In doing this, I noticed a bunch of things that either need to be fixed, still need to be deleted, or need to be put behind a namespace so that including our headers doesn't strangely and unexpectedly …

Even the most casual of acquaintances knows that I really, really hate software that doesn't understand how we do things out here in the Open Source world. We have tools, really amazing ones, called ... "Package Managers" which allow us to "Install" software and describe the "Relationships" between elements. Apparently they can't seem to figure out how to deal with software dependencies and instead they opt for the "copy into tree and fork" method:

Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this …

Jonathan Rosenberg of Google posted a rather long but thoughtful description of what it means to be Open. Although he skips over a few things with a hand waving and a "yeah, I know I just said Open is good, that it's counter to what business types normally think, but in the long run Open is better... it just doesn't apply to these few things for vague reasons" the bulk of his post is both well thought out and correct.

The crux of the whole thing: Open wins.

I agree. We all need to continue to grapple with that and to continue to fight against the urges of "oh, but this thing is the magical exception to that rule." It's not. 

Open wins. Closed can suck it.

The re-enabling of the dlopen()-based dynamic plugin loading has hit the Drizzle trunk. This means that plugins can now be built as shared modules and loaded at will on server startup. We still do not support dynamically loading a plugin in a running server via the LOAD PLUGIN command, nor will we until this can be done without re-introducing global mutexes.

Since this is a feature we turned off a while ago, but that was there before, why mention it? There have been several changes to the system that I thought would be handy to mention.

First of all, Drizzle has a crap-ton of plugins and the numbers are only growing. In the tree now, the default is to build any of them we are able to, and to build them all as shared modules, rather than statically linking them into the server.  Then, from the list of built and available plugins, there is a default list of plugins that should be loaded if no other options are given.

…

I keep running in to issues with how folks use config.h, so I thought I'd clear up any confusion folks have. For those who haven't been following along at home, the autotools (i.e. autoconf and autoheader in this case) generate a file called config.h which contains a bunch of defines to help control the build based on what things exist or don't exist on your system. There are two main rules for this file that lots of folks get wrong:

1. config.h should ALWAYS be the first thing included by EVERY non-header C/C++ file in your project.
2. config.h should NEVER NEVER NEVER NEVER NEVER NEVER be installed.

Why?

For the first point, you must ensure that config.h is included first, because it sets behaviors. It must be included before any system headers because it may contain things that control the behavior of the system headers. It must be included before …

If you’ve ever opened up drizzled/message/table.proto in the Drizzle source tree you will have seen what’s in the table message: the structure that describes a database table in Drizzle. Previously I’ve talked about the Table message more generally, giving a fair bit of history of the FRM file and how we’ve replaced it with both the Table protobuf message and an infrastructure inside Drizzle so that Storage Engines own their own metadata.

Yesterday I talked about the …