Day: September 25, 2006

Oh and Jason, you are hereby kindly invited to join the development of tinymail. A framework for rapidly creating E-mail clients for mobile devices, embedded appliances and soon also web applications.

It having a focus on these targets doesn’t mean that with one extra developer, I can’t focus its development toward a framework (also known as the beginnings of) for a desktop E-mail client. In fact, Modest, a E-mail client being build on top of tinymail by Nokia, is probably going to be a desktop E-mail client for a lot people. After that (being under NDA with Nokia I can’t tell you more), the plan might be (hehe), who knows, to bring it to the Maemo platform too.

It’s likely (grin) that somebody is fixing it to work with the recent API changes which I have been introducing the last few months. These changes and my commitment not to release until all obvious API changes, documentation, unit testing and at least Python language bindings are fully working have been delaying such a release. A Modest release is also delaying that release, as the current idea is to in parallel with Modest, release the first tinymail version.

But then again, people tell me I code tinymail faster than my shadow. I even think that’s a direct quote from Florian (or it was something like that). I guess getting at a first version faster is therefore not really healthy for me anymore. By that I mean: I can use your help (especially if you want it faster).

The development pages of tinymail go in detail about what can be done and what should be done before a first release. They even explain development techniques and details. They also explain how to debug and measure memory usage correctly. In other words, there’s no excuse possible like: “but but, there’s no information about the code”. Lots of such information has been added recently. I often add more.

Oh and if you like Sylpheed, maybe you and me can investigate whether or not it’s doable to extract a libsylpheed out of Sylpheed and use that for implementing a libtinymail-sylpheed as a replacement for the libtinymail-camel? That would indeed be possible, yes. Or maybe a libtinymail-akonadi?

I stopped at a gaz station while I was in a traffic jam, bought myself a can of RedBull, and cause of that I basically opened my laptop and started hacking like a nut. Again.

Another consequence of the RedBull is this blog item.

Whenever we design or redesign a platform, be it a development platform or a user platform, both what GNOME is all about, we should always take into consideration that we aren’t really doing it for just ourselves. Nor are we doing it for just the current generation of people who are active as user or developer.

When redesigning or thinking about a new platform, we are also (and probably mostly) doing it for the next generation of people. The dudes and dudettes who are at this moment adolescents and who will in a near future (or have already) started to create a passion for computers and software development.

If we are going to decide now that a GNOME 3.0 should be as API stable with GNOME 2.x as possible, we are going to give them what is current today. Not what will be current when their tomorrow happens. Therefore I disagree with Johannes a little bit that we shouldn’t make (big) API changes.

We should make the platform of tomorrow. If that means breaking things, well, that’s why we need to increase the major version number. That way, people know that it’s different. Does this mean that we need to change everything like a nut would? No. However, in my opinion it also shouldn’t mean that we should be careful about not changing any API. If existing API is wrong or even a little bit suboptimal, then a GNOME 3.0 should fix that.

(In my opinion) The GNOME platform shouldn’t be called 3.0 for marketing reasons. If nobody is yet thinking about the platform of tomorrow, it’s my opinion that we should stick to the 2.x naming. I don’t think nobody is. Let those people use that 3.0 as place where they can put their experiments and innovative ideas. Let us not block them for another x years. The GNOME platform does need this young and innovative talent.

Let us keep GNOME young. And do as much as possible to attract young fresh minds and ideas. Of course, mix theirs with the existing experience. It will be a win-win situation. Which is, in my opinion, what free software is all about: sharing and passing knowledge. Experimenting. Etc.