iRex Technologies released code

I forgot to mention this, but iRex Technologies has released their source code and adaptations.

From talking with them at T-DOSE and FOSDEM, I have understood that they can use our community help in getting them to understand how to form a healthy win-win relationship with us. I hope the do-people of our community will contact them (for example at the various conferences) and guide them a little bit. I’m sure that this is learning for both sides: we need to understand how technology companies work and what they really need. They need to understand us and about our licensing ideas and ideals. Although I think with Nokia’s Maemo & OpenMoko at least the GNOME community seems to be getting it (like picking LGPL rather than GPL for libraries). Liking the GNOME platform myself, I’m of course biased.

My own personal guideline for this is: do they have the right intentions and are they just struggling to get there? Or do they have the intention to simply steal our work? There’s a huge difference in my opinion.

They had some legal struggles in the past it seems, which I think isn’t abnormal given that they are developing on top of a lot of new technology. It looks like they have the right intentions with our ideals, softwares and licensing. They have a real ePaper device that already and actually works. I’m sure they need quite a lot adaptations to our platforms and application software for the device itself. Why not show that the people who are involved with free software on desktop & mobile are a community of people who are serious with technology companies who want to support their own expertise by leveraging our softwares?

These times are our slot, let’s not miss it again. In general: if you have ideals about software development: please think “do”, not just “talk”. At least that’s my opinion.

Design by contract in tinymail

I finished wrapping the API launchers of tinymail‘s core abstraction library (libtinymail) with require and ensure sections, like Eiffel’s design by contract clauses. Unlike in Eiffel you can’t weaken them in tinymail, you can only strengthen them. I didn’t use nana or ‘DBC for C’ for this, just assertions that wrap the function pointer invocation of the interface’s class struct.

The benefit is that it’s not in the body of the implementation, but rather at the interface’s level: If DBC is enabled and your implementation doesn’t fulfill the ensure clause, then the application will abort. To put it in another way: all implementations must fulfill the full contract of the interfaces that they implement. Also must the client code that uses the interface fulfill the requires clause. So any client code that calls an API yet doesn’t fulfill the input contract, makes the application abort itself (if DBC checking is enabled).

As usual, I try to practice what I preach, here’s the documentation on both using the contracts (enabling the checks) and creating your own ones while doing development for and with tinymail.