A few weeks ago [we released Zanshin 0.2 beta2](/2011/08/31/zanshin-0.2-beta2 "Zanshin 0.2 beta2 release"),
and I'm glad to announce the immediate availability of Zanshin 0.2 RC1. Except if
any showstopper bug is reported, it will be the last stop before 0.2 final.
I'd also like to use the opportunity to report a few changes regarding
contributions and adoption. We've seen tremendous activity on the packaging
front since the previous release:
- It is available for openSUSE and Gentoo as previously announced;
- It is now available for Fedora thanks to Christoph Wickert of
[Kolab Systems](http://www.kolabsys.com),
you can grab it from
[Christoph's repository](http://repos.fedorapeople.org/repos/cwickert/zanshin/)
and it'll hopefully get into Fedora itself soon;
- I got pointed out that it was already available in
[Arch User Repository](http://aur.archlinux.org/packages.php?ID=52024);
- Kartik Mistry volunteered to package it for Debian, so we'll have some good news there soon hopefully;
- Patrick Spendrin confirmed to me that it got added to the KDE-Windows port, and so it was officially
released with the KDE-Windows 4.7.0 release;
- On Mac? I got users building it for themselves reporting it to work, but no
official packaging yet.
I'm glad to see so many people stepping up like that, bringing some GTD goodness wrapped in
Free Software to more and more potential users.
And since some people pointed it out on my previous post, yes we need a website,
screenshots and so on. We've been aware of it for a while, but we've been too busy
working on the software itself. The feedback on Zanshin 0.2 beta2 didn't bring many
issues, so we used the extra time to work on a website. It's not ready for prime time
yet, but we hope to go live with 0.2 final.
If you want to get Zanshin from sources, the tarballs are available, at the same place than
usual on [files.kde.org](http://files.kde.org/zanshin "Zanshin tarballs").
And of course, you can still *git clone kde:zanshin* if you want the bleeding
edge or if you wish to contribute to the code.
Now we're waiting a bit for your feedback. We have exactly one minor bug left in
our list and the future website need some extra polish. Hopefully at this pace we
won't need a 0.2 RC2.
So, I'm sitting right now in the [KDAB][KDAB]'s Berlin offices for what's
probably the last dozen minutes of the KDE PIM Pain Points Sprint (at least
for me, the other guys still have a couple of hours in front of them). We
have been silent so far about what was going on there, and so I will take
the microphone for a couple of minutes. At least we didn't steal the thunder
of the Woshibon guys (looks like they did a great job BTW looking forward
for that to hit my desktop!).
If you follow my blog, you probably noticed that lately when I attend developer
sprints I carry with me shoelaces, sticky notes and other materials to setup
weird boards. When I arrived on thursday night, a surprise was waiting for
me...
[![kanban-thumb]][kanban]
Yes, that neat whiteboard was waiting there to be conquered. I'm actually
glad to see that it's slowly turning into an habit to have this kind of
things in our sprints. The culture is getting there and that makes me happy.
We're apparently ready to experiment with other techniques like the Innovation
Games for instance (which we played for Platform11), etc. We'll see what I can
find to keep that fresh for everyone. ;-)
Anyway, as you probably can figure out from the picture above, it wasn't taken
on the first day but this morning. It started small, but as we were fixing
issues we added more and more sticky notes, in a true flow base fashion...
Since the pace was good enough we could tackle more than originally envisioned,
of course we were also finding sub-issues or corner cases which required specific
care.
In any case the amount of work done is impressive, I won't get into the details
there, but if everything goes well (pending some backporting) the next 4.7
patch release should have a few nice nuggets around performance, migration and
even a bit of usability (I found a fix for a performance issue which turns out
to be also responsible for the message list loosing its selection from time to
time... I know everyone serious at email hate that one).
From the picture above, you can also see that the "Done" lane turned out to
be too small to fit everything (looks like we were pessimistic on the amount
of work which could be done), and someone expanded it partly into the "In
Progress" lane giving it this weird shape... It looks fat isn't it?
Well, fat... it's unlikely we'll turn up like that. There was so much focus
on the work that we had to remind ourselves of stopping for food, hence a
specific sticky note was inserted just for it. It's an important task after
all! ;-)
[![food-thumb]][food]
And if you wonder what focus looks like, I'll leave you with a picture of
our own Lord Volker of Akonadi slaying bugs.
[![volker-thumb]][volker]
Impressive isn't it? If you want to see a few more pictures, you can find them
in the [KDEPIM Pain Points Sprint Gallery][sprint-gallery] available online.
I didn't take many this time, but you'll see a few more people.
Now I should move back to the airport to catch my plane, see you later!
[KDAB]: http://www.kdab.com "KDAB - The Qt Experts"
[kanban]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint/19081652_7733MV#1484678156_qS7KPha6 "Fixed bugs overflow"
[kanban-thumb]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint/i-qS7KPh6/0/S/IMG0512-S.jpg
[food]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint/19081652_7733MV#1484678198_XkbkGRb "Food!"
[food-thumb]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint/i-XkbkGRb/0/S/IMG0513-S.jpg
[volker]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint/19081652_7733MV#1484678350_gSTgKSQ "Volker Krause at work"
[volker-thumb]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint/i-gSTgKSQ/0/S/IMG0518-S.jpg
[sprint-gallery]: http://ervin.smugmug.com/Events/KDEPIM-Pain-Points-Sprint
Zanshin, the TODO application which helps keeping your mind uncluttered
is back! After one month of waiting, we are delighted to announce the
immediate availability of Zanshin 0.2 beta2!
The focus has been mainly on bugfixing, but we also did a couple of
usability adjustments here and there. Also, thanks to the awesome Nuno
Pinheiro, we have an application icon (previously we were just hijacking
KOrganizer icon). This new icon is lovely, thanks Nuno!
The source tarballs are available, at the same place than the last time on
[files.kde.org](http://files.kde.org/zanshin "Zanshin tarballs"). If you want
to use it on openSUSE
[my repository](http://download.opensuse.org/repositories/home:/ervin/ "home:ervin openSUSE repository")
has a package for Zanshin, but it's now also available on the
[KDE:Unstable:Playground repository](http://download.opensuse.org/repositories/KDE:/Unstable:/Playground/ "KDE:Unstable:Playground repository").
Last but not least! Zanshin is also now packaged for Gentoo. Thank you to
Matija Suklje for working on it.
And of course, you can still *git clone kde:zanshin* if you want the bleeding
edge or if you wish to contribute to the code.
You can also contribute by helping us reaching more users:
- packaging Zanshin for your distro, we still miss big ones like Arch, Fedora
or Debian/Ubuntu;
- making sure Zanshin runs on MS Windows, apparently Patrick from the KDE-Windows
team was toying with that during DS but I'm not sure how it went;
- or making sure it runs on Mac OS (we're not aware of any effort on that
platform yet).
Now we're relaxing a bit, and waiting for feedback to see what needs fixing
for the next release. Depending on the defect rate next one could be 0.2 rc1.
Looks like we're getting closer and closer from 0.2 final!
We released Zanshin 0.2 alpha2 in May, it was about time we got our acts
together to prepare another release. So today I'm happy to announce the
immediate availability of Zanshin 0.2 beta1!
It is the result of further bugfixing and testing work. We got some
feedback from early users of 0.2 alpha2 and it's been reflected in our
bug hunting efforts.
Since the previous one was an alpha we still had the freedom to add a
couple more features. The features introduced for that beta were rather
non-intrusive though, the main ones are:
- the ability to set categories on projects, todos inside such projects
automatically inherit from those categories (greatly reduces the tagging
needs);
- the ability to synchronize collections directly from Zanshin;
- and last but not least a Kontact plugin, now Zanshin can work embedded in
Kontact (this one was actually a feature request, I didn't even think
about it). :-)
Now that we're entering the beta cycle, we're also publishing
[source tarballs](http://files.kde.org/zanshin "Zanshin tarballs"). Of course,
I still produce packages to openSUSE, although for the time being they're only
built against KDE:Unstable:SC, I'm waiting for kdepim 4.7 to hit other repos
before supporting more. Those packages are available in my
[home:ervin repository](http://download.opensuse.org/repositories/home:/ervin/ "home:ervin openSUSE repository").
And of course, you can still *git clone kde:zanshin* if you want the bleeding
edge or if you wish to contribute.
We plan to release Zanshin 0.2 beta2 somewhat soon after the Desktop Summit.
We're only in bugfixing and stabilization mode now, no new feature will be
introduced until we release 0.2.
Enjoy!
After quite some work on stabilizing, testing the core, and adding
some extra features, I'm happy to announce that I just tagged
Zanshin 0.2 alpha2!
The big highlight of this alpha is the availability of a new
krunner plugin, so that you can easily collect todos even when
Zanshin isn't running. Bring up krunner, type in "todo: buy
apples", and the newly created todo will be waiting for you in your
inbox the next time you look at your Zanshin window. Collect from
anywhere on your desktop now!
We also added an extra dialog to configure Akonadi resources which
is displayed on first run, and better defaults for the columns and
window sizes, which should provide a smoother experience for new
users. And of course it comes with more automated tests, and
bugfixes.
If everything goes well, it should be our last alpha, and we should
proceed with 0.2 beta1 next. For those interested, it is available
for openSUSE in my
[home:ervin repository](http://download.opensuse.org/repositories/home:/ervin/ "home:ervin openSUSE repository").
For the people wanting to build from sources, it is still a git
clone kde:zanshin away.
I'd like to thanks Mario Bensi and Benjamin Port who have been
fearless bug hunters for that release. Way to go guys!
PS: As mentionned, I package it for openSUSE myself as it is my
distro of choice, but we're obviously looking for packagers
targetting other distributions. If you're already working on such
packages, or are willing to work on them, please get in touch with
me for improving synchronization toward the 0.2 release.
Some people might remember that I was rambling a while back about a
TODO management application named Zanshin. It even has a few
users... they have probably been wondering why it got stuck at this
mysterious non advertised 0.1 version.
Don't fear anymore dear users, Zanshin is not dead, it is pretty
much alive, and we just tagged 0.2 alpha1 today!
It took us a while, we had to rewrite quite some bits in order to
benefit from the new additions of the Akonadi ecosystem we would
have missed otherwise. So we're back, and we plan at least one more
alpha, before going in the beta cycle. It is your chance to give us
feedback early on to get a solid 0.2 release.
Of course it is an alpha, so it might not suit you for production
use... Personally I switched to it in production and it didn't burn
my home yet. It will soon be available for openSUSE in my
[home:ervin repository](http://download.opensuse.org/repositories/home:/ervin/ "home:ervin openSUSE repository"),
once it gets out of the build farm (already the case for factory,
not yet for 11.3). If you're building from sources, it's only a
"git clone kde:zanshin.git" away (we're actually among the first
projects to migrate there).
I'd like to give a big kudo to Mario Bensi, who is working with me
on Zanshin. He did a tremendous job on that alpha. For the last
month I've been mostly giving architecture directions and reviewing
patches... still I had difficulties to keep up with the patch
stream he was sending my way. Great job Mario!
PS: As mentionned, I package it for openSUSE myself as it is my
distro of choice, but we're obviously looking for fearless
packagers targetting other distributions.
I previously blogged about the new IMAP resource in Akonadi. We
were aiminag at getting this resource from the start, but here is
the not so secret story: this effort gave birth to another
component, namely libkimap.
The journey started because we really wanted for KDE to have a
strong and efficient IMAP support. Since we're not really into
reinventing the wheel if we can avoid that the journey started by
looking at existing IMAP solutions we could reuse. The natural
first contender of course was to reuse our old IMAP ioslave which
we currently use in KMail and build the resource on it. But really
it is showing its age now, and the interface such ioslaves expose
are too limited for our needs (for those in the known of KIO
internals: it would require an extensive use of the special()
method, or command encoding in urls...). So we have been evaluating
a few other contenders coming from various mail clients, but
unfortunately most of them are either exposing synchronous API (not
convenient for something event driven like an Akonadi resource), or
very tied to a MIME implementation (which was a no-no as we needed
to use the resource with kdepim's MIME implementation).
Indeed this journey didn't start quite well... We had to produce a
new IMAP implementation. So a new quest started, one for an
adequate API design. At that point we knew we wanted something:
fast, memory efficient, asynchronous and easy to extend (as the
IMAP RFC has plenty of extensions).
First, let's examinate the "fast and memory efficient" constraints.
Around the same time I got started on libkimap, Andras Mantia
(fellow KDABian and hacker extraordinaire) was working on making
the Akonadi server protocol handling faster and more memory
efficient... And as a bonus, the Akonadi protocol for the lowest
level parts, have quite some similarities with IMAP as it was
modelled after it. So far so good, I could reuse Andras work on the
new IMAP stream parser. It has been a two way collaboration as I
also found bugs in there which got fixed. This parser is now the
core of libkimap, although it is hidden from the public API, it is
for a great part responsible of the good performances of the
library.
Then, let's solve the "asynchronous and easy to extend"
constraints, those had a direct impact on the API. For that we rely
on the good old "job based" API. You just need to create a Session
object which holds a connection to an IMAP server and queue Jobs on
it. Jobs are then executed sequentially. We have jobs for a lot of
things: mailbox listing, fetching messages or headers, retrieving
annotations, quota information, ACLs, etc. And that's where the job
based API gets interesting, we need to extend it? Just add a job,
binary compatibility will be kept and so on, it makes it much
easier to manage it over time.
Oh! And of course, since we still care about performances, each job
is equipped to be able to pipeline several IMAP commands to the
server, which dramatically reduces latency. So you guessed it, jobs
don't map 1:1 to IMAP commands, this way we can provide some
convenience to developers because they get pre-shipped micro
behavior (for instance, listing mailboxes and taking care about the
namespace extension results always in the same list of commands, so
we wired it in jobs which pipeline commands).
So we indeed solved our initial problem, we made an asynchronous
IMAP library which is fast, efficient and easy to extend. It also
tries to be clever when that actually makes it more convenient for
developers (see the pipelining example above), but not too much,
allowing to have a fine control on the higher level logic and
strategies you'd need to implement in your application. And thanks
to this strong basement, we could tackle the task of building the
Akonadi IMAP resource on top of it.
As a post scriptum: is our library tied to a MIME implementation?
Well, like others we're tied to one: libkmime, available in
kdepimlibs as well. You can't really get around that in the end.
Indeed, for fetch operations if you try to be independent of any
MIME implementation, you end up implementing your own subset of
MIME. That said we tried hard, and managed to keep that coupling as
minimal as possible, and in fact only the FetchJob really depends
on libkmime, everything else is independent of it. So, it wouldn't
be a big cost to implement your own FetchJob variant using another
MIME implementation.
And finally, as a post post scriptum, if people out there wants to
grab it and play with it, it is in our kdepimlibs module on trunk.
You can browse it online here:
[http://websvn.kde.org/trunk/KDE/kdepimlibs/kimap/](http://websvn.kde.org/trunk/KDE/kdepimlibs/kimap/).
In my previous post, I've been discussing our progresses on some
protocols support, and that Akonadi could now be fed with quite
some mails. That's neat to us developers who can make application
harvesting data in there... But for the user it's not really useful
if he can't see the data. Well, recently I've also been working on
showing up collection statistics we can get from Akonadi, and also
I ported KMail message list view to Akonadi (also making it a
separate library). In the meantime, the fearless Andras has been
porting KMail mail reader view to Akonadi (also making it a
separate library). In fact, it is the current thread in the huge
task which is the porting of KMail to Akonadi. We're ripping KMail
apart, each important set of features are factored out in a library
and ported to Akonadi. In the end we'll have a KMail completely
based on Akonadi. But also, it will be much more modular, reusable
for other mail clients, but also news readers, etc. Which means
that the new architecture will be better suited at supporting a
wide range of devices and a good base for future works. Anyway,
both Andras and me had a small test application for each of our new
frameworks... So I took some time to merge the features of both
into a single application: the Akonadi Mail Reader. This new baby
is mainly a prototype to toy with ideas and try out the components
we're making out of the monolithic KMail. Still, it weights just
under 400 lines of C++ code, and you can completely browse all the
mailboxes you configured in Akonadi thanks to it. Of course, here
is the obligatory screenshot: [caption id="" align="aligncenter"
width="320"][](http://ervin.ipsquad.net/share/akonadimailreader.png)[/caption]
It looks so much like a miniature version of KMail that it is
almost scary. But don't fool yourself, there's a lot to do to have
a full fledged KMail which will be only based on Akonadi. We're not
there yet, still it is nice to see the whole thing taking shape, in
particular to reach the point where you can actually read your mail
over IMAP using this small prototype and feel almost at home with
it thanks to this familiar touch. :-) From my point of view, the
KDE culture of working a lot with components really pays off. KMail
was first created at a time where this KDE culture didn't reach
it's full potential yet, hence why we need to refactor it now. But,
following this culture it is really nice to see that we'll end up
with small packages of mail client functionalities, and, that
thanks to them and to Akonadi, it will be easy to integrate them in
any application. We made a relatively complete mail reader in under
400 lines of code, so simply displaying mail content in your
application or a message list becomes a trivial task.
We got a few posts lately of people recently hired by KDAB, and
suddenly it made me realize that I didn't make such a post when I
got hired... almost two years ago. I guess it's a wee bit late to
write one now. :-) Buuuut... I figured out that I could post
something about what I'm doing in KDAB (OK! OK! Sebas has been
kicking me for days to make it happen). And if that proves to be
enjoyable writing for me, and enjoyable reading for you people I
may do that again from time to time. So what am I doing in KDAB
these days? Well, for a while now I've been helping the pimsters
with the refactoring of our PIM suite toward making it purely
Akonadi-based. There's quite a lot of work going on in this
particular space, and I've been focusing mainly on the IMAP
support. It has been an interesting journey so far which started
with evaluating the IMAP stacks we could reuse. First on the ranks
were obviously our old ioslave which served us well, and some IMAP
code Tom Albers developed for Mailody. It turned out that we had to
abandon the ioslave. It served us well for years, but didn't work
for some of the plans we had (most notably for adding the IDLE
support I'll talk about later). While working on IMAP I had a
couple of ideas on how to still use the old ioslave, but they were
really nasty and hackish... I think it was a clear sign that the
ioslave reached its full potential and keeping it alive was a dead
end for the future. So after this investigation phase it has been
decided to write a small library for IMAP. We already had some
codecs convenience in the KIMAP library from kdepimlibs so we
stepped up to extend it. And for the API we quickly settled on a
job based one because we had strong needs for asynchronous
operations. We clearly don't want to be blocking waiting for some
IMAP command to be processed. So our dear old KJob friend has been
used for that, and it turned out to be a very good choice. We've
been relatively quick at having enough useful jobs implemented in
the library once I wrote the core bits of the API. I got quite some
help from Andras Mantia for that. By the way, I think that just
like our almighty David Faure, Andras is having a few clones
himself, once he gets on a task he going so fast you'd better not
be on his way... something suspect is at play there, I'm sure. ;-)
In any case, Andras (and his hundreds of clones) help was welcome,
as it helped me move higher in the stack and work on the Akonadi
resource itself. I'll just slow down a minute and explain for those
not in the known what an Akonadi resource is (for the ones in the
known, you can skip to the next paragraph). So Akonadi is our grand
unified layer to access data in your desktop, applications talk to
it and then they have to understand only the akonadi concepts (in
short: items, and collections of items). Of course you need to get
your items and collections from somewhere, and that's the role of
Akonadi resources. They just get data from "somewhere" and put it
in the Akonadi cache where the applications can make use of them.
Obviously for a future Akonadi based KDEPIM suite we needed an IMAP
resource to access your mail on IMAP servers. And if you followed
closely, that means that soon applications won't even need to know
where the data comes from, you write just an Akonadi client and it
can go over: POP, IMAP, whatever! It all depends on the resources
your server loaded. Neat huh? Work on the IMAP resource started
only a few days before the Akonadi Sprint in Berlin which I was
attending. And the job based API quickly proved that it was the
right choice. I've been pretty quick at building the resource on
top of it (and Andras was producing new jobs for my own consumption
at a furious pace). At this meeting we had kind of an informal
contest about who would come up first with an Akonadi resource
which can list a mailbox (since at the time POP, IMAP, and maildir
support were all developed and started around the same time)... it
turned out that I heard about this informal contest when I was
putting the finishing touch to the mailbox listing. Sooo... DONE!
:-) I didn't stop there of course as more features were needed to
have a complete resource. And I've been working on that almost
exclusively during the sprint. Discussing with Volker (aka the
Akonadi overlord, the alpha and omega of its design) we came up
with nice design ideas for the groupware support (in particular
Kolab)... but that's probably a story for another time... Some time
after the sprint, I flew over to other tasks in PIM land. And left
the Akonadi IMAP resource untouched for a while. I came back to it
only last week to implement in trunk one long requested feature:
the IDLE extension. -- And obviously that's where the name of this
blog post come from, just like my favorites novels you get the
title only in the last chapter or paragraph. :-) -- Thanks to this
extension, if it is supported by the server, you get notified from
changes by the server itself. For instance, it is not needed
anymore to poll every N minutes to notice that a new mail appeared
(I think this feature is sometimes called "push mail"). For the
user that means, that the IMAP server can now notify the client of
new emails, emails "arrive" faster at the user, and you can save a
lot of unnecessary mail checking. Really handy! I committed IDLE
support in trunk this week, so it will get released with our 4.4
release. In the meantime you can start playing with the Akonadi
resource when our 4.3 release will be out, as we already ship it
there (although it's not used by default, see it more like a
pre-version of what's coming, for instance this one doesn't support
IDLE). That's it for today, I hope you enjoyed those pimsters news
from the trenches of the IMAP battle. See you later!
