Author: admin

Since today for both POP and IMAP it’s possible to, while you are retrieving summary items, start opening (downloading) uncached E-mails. On IMAP this is done (a few weeks ago) using an extra socket. With POP this is done (today) by throwing RETR commands in between the TOPs that are needed for the summary fetch on the same connection (most POP servers lock the access to one connection per user). It’s also possible and well tested to have Push E-mail events of 1000ths of new and expunged E-mails. It’s possible to see your headers (summary) view to get filled up while retrieving summary info. All this while Tinymail attempts to keep the bandwidth acceptable low for GPRS.

Jose Dapena Paz also recently added support for removing attachments from already cached E-mails. This is a feature that is interesting for devices that don’t have a lot of (flash) disk space. Again retrieving the uncached attachment should also work. Partial retrieval (initially retrieving without attachments) is working, but suboptimal. We’ll be working on improving features like this soon. POP is of course much more difficult as there’s no way to know where a MIME part starts nor to select which of the lines you want to retrieve.

Huge amounts of small and big things are being fixed. Required features being implemented. A lot of work is being done.

By changing the way work is done, electronic networks may lead to a new kind of economy centered on the individual. — Thomas W. Malone and Robert J. Laubacher.

In business, I believe the future lies in loosely connected individual contractors, dynamically coming together to attack a project or idea. — Rob Taylor.

When Rob blogged about it, I decided to order my copy of that document. I just read it. Sounds good to me.

Let’s talk about it at GUADEC. I will arrive at BHX the 15th around 13:50 by the way.

I would, out of the blue, like to highlight the work the people doing the Anjuta 2.x series have done. I have been working with whatever is in Subversion (and before that, CVS) for multiple years now. It had its weeks of total instability, weeks of total stability too. But on features, especially on features, it has seen vast improvements. It’s a totally different experience when compared to the 1.x series of Anjuta.

pvanhoof@schtrumpf:~/repos/gnome/anjuta$ sudo make install
...
 /usr/bin/install -c -m 644 'anjuta.desktop' '/opt/anjuta//share/applications/anjuta.desktop'
make[2]: Leaving directory `/home/pvanhoof/repos/gnome/anjuta'
make[1]: Leaving directory `/home/pvanhoof/repos/gnome/anjuta'
pvanhoof@schtrumpf:~/repos/gnome/anjuta$ 

They are now working on integrating some bits and pieces with scratchbox. The integration with autotools (which utilizes gnome-build) is unimaginable good. I’ve become a total addict of features like the symbol browser and the symbol searcher. I’m sure I’m missing quite a lot of other features that could potentially glue and duck tape me forever to Anjuta’s 2.x. A requirement for any distribution that I’ll use has been, since more than a year, that I can easily build whatever I find in Anjuta Subversion -> “apt-get install gnome-devel”. Thank you, Ubuntu and Debian, for that.

I believe we need more of our developers to use this project. That way we can get this project to become a product, too. Because frustrated developers will fix Anjuta’s code. In contrast, I haven’t seen a lot of GNOME-developer’s frustration get converted into code for the Eclipse CDT project. I’m confident that since Anjuta is purely GNOME/Gtk+ style of development, Anjuta would be different.

I often got so pissed at whoever broke the search dialog of Anjuta’s Subversion this time. Forcing me to go back to ‘grep’ and ‘find’, to find things. Slowing me down. But then again, I should just help them in stead. Right? In stead of remaining pissed, I’ll truly apologize for being a user of their software yet not having contributed a lot to their fabulous 2.x series. On the bright side, I did do some work on the file dialog of the 1.x series of Anjuta. That code has now vanished and been replaced by superior things, of course.

I’ll put an icon on my desktop that throws Anjuta’s process into gdb. Being a developer you’ll be surprised how often you click it and then actually fix that annoying bug in stead of just restarting the software. I used to do this with Evolution too.

We’re getting there. Although I’m thinking in months, not in weeks. If you’re working on a feature for Tinymail and you want it in its first release: you better start hurrying up.

It’s becoming a product that just works. A lot of the release work will be low hanging fruit like getting gtk-doc in perfect shape, making sure ‘make distcheck’ does the right thing, killing a few more major defects and writing some more documentation.

When those items are finished, the project can be delivered as a product. Above all, it must earn the status “product”. That’s the point where I’ll release a first version.

Rob (Taylor) used to be one of the lead developers of the Telepathy project, he co-founded Collabora and is now starting up Codethink Ltd. He has worked on HAL, D-BUS, Telepathy and various other bits and bytes of the many GMAE and GNOME components.

Although not the only participant in this, I believe he played an important role at encouraging a number of companies in working with us, the GNOME Free Software community. He combined his technical expertise with business expertise.

It’s therefore my opinion that Rob has become one of our most skilled and needed people. At LinuxTag we agreed to start working together under Codethink’s flag. I will be the first contractor to come on under the new Codethink plan.

With our expertise we are planning to change the mobile landscape. We’re both passionate people who’s goal is to make the difference, which is exactly what we’ll do.

The Evolution maintainer announced a new release. This time the release fixes a significant security problem.

The problem is a remotely exploitable one. I strongly suggest everybody updating his or her Evolution setup. Even if your Evolution package is incredibly old. I think nearly all Evolution’s versions are affected.

Evolution-data-server:
=====================
...
#447414: Security Fix - negative index of an array (Philip Van Hoof)

At LinuxTag Rob and I met and talked quite a lot to some Qt and KDE guys. We somehow came to the conclusion that a combined conference for our communities would be something positive. We concluded that the majority of people in both communities who truly matter (the people who do things, not the people who only talk about things), enjoy the competition between GNOME and KDE. That they love the other guys. That competing each other is giving both project’s members a reason for innovating their own project. Yet that the same competition should focus on being the best at what we do while that this competition should not make it difficult for the many companies and users that use our infrastructure.

Therefore we agreed that as much as possible of the D-BUS API should be shared between the KDE and the GNOME projects.

Our conclusion was that we need more social networking for this synergy to happen. We concluded that both Akademy and GUADEC share the same conference atmosphere and goals: they are both heavily oriented at meeting each other.

I would therefore, hereby, like to propose using the FOSDEM conference to pioneer the idea of perhaps in future having the GUADEC and Akademy conference to take place at the same time and location. Note that in this idea neither GUADEC nor Akademy change names nor that it would become one big conference. Note that it’s only an idea and that I think for it to succeed, it needs a pilot event. FOSDEM can be used for this.

We could play with the idea of having a few shared social events, like a game of soccer. Maybe making music together (as that was one of the greater ideas at GUADEC last year)? Social events with an emphasis on cooperating yet competing? Friendly competing!

I’m planning to ask the FOSDEM organisation to, in stead of two rooms, have one big room for both GNOME and KDE people. Or two rooms while mixing the presentations equally over the two rooms.

I hope I will be flooded by opinions coming from both sides, as this is probably a hard decision. Though I believe that both communities need to do this for our users and for the companies who get to deal with our differences.

I would like to state, clearly, that as a GNOME community member: I love KDE, I love the people who do KDE, I clearly disagree with a lot of their strategies and architecture ideas and I totally love the competition that got created by this disagreement. Let’s strengthen both and get them to share as much D-BUS API as humanly possible. Yet let’s keep competing each other by trying to provide the best implementation behind those APIs.

Let’s ignore the people who think that we are duplicating efforts, as we know we are not.

Let’s be friends who meet each other often and who have respect for each other. Let’s agree to disagree, but let’s agree on the things that we can easily agree on: D-BUS API.

Finally and most importantly, let’s not just talk and have good intentions but let’s also make it happen. Let’s compete in style.

Look at those cute little devices! All doing Push E-mail with a Tinymail based E-mail client. All at the same time! A Nokia N800, a Nokia 770, my Feisty desktop and a OLPC. Next on the list .. the iLiad and Openmoko?

Video demo, Youtube version

Just like with the OLPC build I have fixed the builds for GPE and the builds for Maemo with older distributions like Mistral and Gregale (the rootstraps in Scratchbox that’ll compile for your Nokia 770). The build for Maemo’s Bora rootstrap (for the Nokia N800) and the one for GNOME desktops were of course already functional.

On all these devices and platforms (N800, 770, OLPC, GPE) you can now out of the box compile yourself a Tinymail demo user interface with the latest features. I will bring a few such devices with me at LinuxTag. Although very unfinished, I can demo a recent development version of Modest running on my N800 too. Which, by the way, is becoming more and more useful as fine dog food. The GPE and GPEPhone folks told me they will bring some GPE devices too (it wont take long before we’ll have the Tinymail demo ui running on all of them).

~# apt-cache search empathy
~#

While preparing my OLPC laptop for LinuxTag, I noticed some glitches in the OLPC build of Tinymail. These have now all been fixed and the demo-ui will run and work as-is. You will of course need to edit your $HOME/.xinitrc to override the “exec sugar” with an “exec xterm”, start matchbox-windowmanager and then the Tinymail demoui binary.

You can also try to use the development console which is accessible when typing the [alt]+[=] key combination. But I found it quite hard to make the application usable this way (it gets pushed to the back by the Sugar window manager or something).

The demoui is indeed not suitable nor has already been made suitable as a typical Sugar application. I would of course welcome attempts at this.

To compile do this on any typical x86 computer:

./autogen.sh --with-platform=olpc --prefix=/opt/tinymail-olpc
make && sudo make install

Now tar /opt/tinymail-olpc and untar it into the same directory on your device’s root filesystem.

After deployment follow these instructions for creating an account and in the xterm just launch /opt/tinymail-olpc/bin/demoui.

It’ll ask you for the password each time. I haven’t yet found which password storage API is going to be used on the laptop, so the platform specific implementation is just going to call a GtkDialog box that will each time ask you for the password.

Hey Benjamin, good that you mention “creativity” and Mozilla in the same blog post.

I’m sure the people at Mozilla and the distributions have a slightly better solution to this current situation of having to do funny things in your configure.ac to figure absurd things out. Things like having to search which of the Mozilla development packages are available: a developer can choose between nss.pc, mozilla-nss.pc, firefox-nss.pc and xulrunner-nss.pc. I’m sure there are a few more too. Like nspr.pc, mozilla-nspr.pc, firefox-nspr.pc and xulrunner-nspr. And like xpcom.pc, mozilla-xpcom.pc, firefox-xpcom.pc and xulrunner-xpcom.pc. And of course also gtkmozembed.pc, mozilla-gtkmozembed.pc, firefox-gtkmozembed.pc and xulrunner-gtkmozembed. Just to make sure our configure.acs will be bloated like crap just for figuring out what the system actually has installed for those libraries.

I wonder what the use of pkg-config is if everybody starts doing that, Mozilla team?

For some fun reason they also decided to have -rpath in some of their “Libs: ” lines too. Making it totally fun for the maintainer to figure out why certain symbols can’t be found in a lot of circumstances (like when you used to have a function that was static, and now became a non-static, those rpath tricks will trick your linker into trying to use the installed libraries that are located in the prefix location if you once did a “make install”).

Awesome things if you don’t know that and expect sanity from pkg-config configuration files.

Tinymail’s camel-lite is still being developed extensively. While making changes, though, I made sure that the API that once got implemented by some existing custom Camel providers more or less stays the same. Myself, I added support for a bunch of Lemonade -and related features and improved the bandwidth consumption a lot in the IMAP provider, while adding support for summaries in the POP provider. These changes included a huge amount of bug fixing and other improvements too, of course. Especially on memory consumption. The majority of the changes, though, happened in the implementation, not so much Camel’s API.

Although an existing Camel provider usually needs a lot of bandwidth improvements before being acceptable for usage for Tinymail’s target audience (I looked at a lot of them, they do), you can very quickly make any such existing provider work with Tinymail. It comes down to rewriting one method: the CamelFolderSummary::message_info_load one. Noting that even the CamelFolderSummary::message_info_save stays the same. The load one needs to be rewritten because it’s in this method that in stead of read()-ing the data from the FILE*, you’ll have to implement getting the pointers from the mmap(). At entry of the method you’ll get the offset where the data that you wrote to the file using CamelFolderSummary::message_info_save starts. You are responsible for moving that offset further (for example += it).

The file I/O API of Camel has been modified to always do data padding, which is necessary for some architectures with mmap(), and to always end strings with a ‘\0’, which is of course important when pointing to offsets and using the pointer as a char pointer C string. You’ll always do it right if you use the standard Camel file I/O API.

I created a trac wiki page on the Tinymail documentation describing how to do this. It has some examples too. On bandwidth it’s of course vital to understand that a lot Tinymail based E-mail clients will be used on flaky networks like GPRS. Dealing with being offline (being very good at synchronization, while trusting that the connection will die at totally unexeptected locations in your code) and dealing well with timeout situations is of course very important. Compression and SSL are vital too.

Yes me shall.

Most E-mail clients want some sort of queuing mechanism. Not surprisingly every developer has the desire to implement his own queue thing. This by itself is not a big problem if only they create a wrapper for their queue that implements my interface.

After that, I have some guarantees about that implementation that I can use to develop higher level functionality. Guarantees like the availability of a specific certain API. I need to fine tune the Design By Contract clauses for this little bit more, but these queue interfaces are well documented and by-contract defined (or going to be even more strict).

A few months ago I announced this AsyncWorker thing. A normal person would maybe simply require that library and assume that all developers will bend over and let me put my AsyncWorker … where the sun doesn’t shine? That’s not Tinymail’s concept though: flexibility and being adaptive to Change is.

Although I added a libtinymail-asyncworker library that implements a default queue implementation, you can implement your own. I believe a lot E-mail clients will actually want to do that: maybe they want very tight integration with and a lot of control over their queue? I can imagine that.

The trick, though, is to build a bunch of standard queue functionalities yet make it possible that they all share the same top level queue. For that, I used the decorator design pattern. All the default queues, except the asyncworker one, implement the queue interface and will aggregate one too. Usually that will be a base queue implementation, like the asyncworker one, but it can also be any of the queues (nested situations, why not).

I’m starting with a queue that will in the background get full messages, one that will act right after a full message is received and one for sending messages.

The one that will act will for example (depending on your mua’s policy) share a top level queue with the one that gets full messages in the background. It will have tasks with a higher priority though: acting can for example mean “to display that message in the message view”. While perhaps messages are being queued for retrieval? While Push-Email events cause get-message tasks to get added to the queue?

The thing is, Push-Email right now will only get the summary info of a message. But if that Push E-mailed E-mail contains a calendar item, then you’ll need to fetch that if your application wants to do something interesting with the calendar content. Like playing a different ring-tone if it’s a calendar item coming from your boss? Your application can in that case use a queue that will act with something, right after the queued task received the full message.

You guys remember that Push E-mail events can be caught using a TnyFolderObserver, right? An implementation for your folder observer’s update method could be “put a task on the act queue that will add the calendar item in the E-mail to the device’s calendar” once the task finished receiving the message. That is already possible with Tinymail today, yes.

I’m writing documentation right now. A bunch of it is already available, but the best page to start is this one: TnyQueue and TnyQueueTask. I need to adapt my gtk-doc scripts to enable adding the API to the API reference manual of Tinymail. All of the API is already documented fully, though. The script just isn’t yet adding it to the gtk-doc build.

Note: that some other E-mail clients don’t have this amount of flexibility for queuing just means that they are too limited for mobile applications. Mobile applications need to cause events to wake the person up. I believe that Push E-mail is just the beginning of all this. Future will tell, of course.

And Tinymail will be ready for that.

It has a very interesting item in the Applications section!

I wrote this a few times already, but documentation is something that needs to be repeated over and over again. Until it bores you so hard that you will do it just so that the idiot who keeps repeating about it, would stop. Exactly.

For that reason I keep repeating it so often to myself, that I myself will get bored of hearing myself repeating that it’s extremely important. In the end it’s all about self-inducting psychological tricks, indeed. Forcing yourself, forcing myself.

Today I started cross-referencing Tinymail’s manuals and documentation. I for example created links to the API reference manual and started pages with some minimal documentation about types being mentioned in a manual.

My opinion is that any software is pure vaporware until it’s fully documented for at least its target audience. This means that Tinymail will be vaporware until its documentation is more than perfect (as my goal for the project is to get it better than the current best). Undocumented software by definition sucks in my opinion. Doing free software isn’t a valid reason for having no documentation.

Unit testing, though, has been slipping a little bit (luckily not completely). I’m hoping to see GNOME Buildbot becoming ready and integrated with GMAE so that this will psychologically force me and other contributors into making sure that it will never slip again.

Last few days together with Murray I have been working on for example the status infrastructure in the Tinymail framework.

We simplified how to internally deal with status callbacks, we made sure that they’ll happen in the right order and wont happen after the final callback happened.

I created two video demos this time. A first one is for most people. It will show you how much status you can get out of the framework in case you will create a client on top of Tinymail. The video shows you the demo user interface with its ‘glamorous’ :-) progress bar (which shows a lot more status than “some other” E-mail client’s progress user interface).

User video demo, Rescaled one on youtube

A second is a technical video demo for people who want to learn how Tinymail works. Although it’s mentioned, it doesn’t really try to illustrate how to use the API to for example update a progress bar and show a status bar. The technical video demo shows you how Tinymail deals with launching status callbacks internally.

Technical video demo

I did the technical one with a normal video camera. That’s why the quality isn’t ideal. After doing that one, while not being satisfied, I discovered xvidcap for making the user video demo. Its quality is excellent. Therefore I recommend xvidcap for screencasting and I’m probably going to use this tool more often indeed. Finally I use Cinelerra to glue audio to it, cut and paste the “eums”, “swallow” and “grrmm”s away.