One of the Modest developers!

Federico, I’m not going to make yet another long and technical blog post about this, because it’s rather obvious how it works. But you can make a db-cursor or a cursor-like API for a query that is solved at the service and kept in a session.

What I don’t like about it, is that it more or less requires each client of the service to keep a local copy of the calendar or contact data in its own memory. At least all the data that matched the search query. This data is not really small per item. In fact, it’s quite large. It never really surprised me a lot that both the calendar component of Evolution’s shell AND the Evolution Data Server consume quite a lot of memory.

Yesterday I posted how to make a Web 2.0 E-mail client. Although a joke, some people kinda agreed that this is the future.

A few days ago I got this reply on one of my blog posts:

Phil:

Your post — and your work — miss the point entirely. Nobody cares how email works, they just want it to work.

Gmail (and most other webmail applications) makes everything else obsolete. I can’t imagine why Evolution is even shipped with Gnome anymore.

Web-based email clients are the standard.

-Anon

I just finished the E-mail client the guy wants. Here it is!

using GLib;
using Gtk;
using WebKit;

class Web20EmailClient : Window {
	WebView view;
	construct {
		view = new WebView ();
		view.open ("http://gmail.com");
		view.set_size_request (640, 480);
		add (view);
	}
	static void main (string[] args) {
		Gtk.init (ref args);
		var win = new Web20EmailClient ();
		win.show_all ();
		Gtk.main ();
	}
}

Introduction

IMAP’s biggest problem is poor server implementations and big vendors who are not really supportive towards each other being the ones defining it. Not because they are the only ones at IETF who are vocal about the protocol. It’s because if the big players don’t implement the new enhancements, it basically boils down to not being used and the E-mail clients not adopting it. Quite funny is the fact that all those big players have their own closed protocols for E-mail too. That all those big players seem to consider their IMAP support to be of secondary priority.

I have found myself foster parents for Tinymail.

One of the difficult jobs of a maintainer is delegating tasks to the right people. In my opinion a good project leader is someone who motivates people by giving out responsibilities.

This is why Igalia is doing Tinymail’s 0.0.8 pre-release this time.

I just finished making Tinymail’s .NET bindings actually usable. To test whether the binding works I wrote a small demo user interface in C#.

I added minimal documentation too.

Because Tinymail does quite a bit more with the GTypeInterface GType than Gtk+, Mike’s GtkSharp code generator for this had a few problems. I expected it to fail a lot worse, though. Without any improvements it did already get pretty far by itself! Mike and me have been pushing its code to support even the most crazy kind of things that Tinymail is doing with interfaces in GObject-C. There is still a lot of room for improvement for both Tinymail’s resulting binding itself and GtkSharp’s Gapi parser and code generator.

With current trunk of GtkSharp and after applying two patches for its generator, it’ll make you a quite nice .NET API now. I’m of course working with Mike on getting proper solutions for what I had to patch upstream in GtkSharp’s Gapi.

I would like to thank Mike for his patience and help while I was making this binding work. I hope other library maintainers will use Tinymail’s one as knowhow-offset to get their own bindings working in .NET too.

There are still a few rough edges, but I’m confident that I’ll soon have those fixed. Other than that, here it is: the first in C# programmed E-mail client that uses Tinymail.

Took me around two minutes to throw the UI together and connect a few signal handlers to the treeviews with MonoDevelop.