PIM developer sprint

Last weekend we had a PIM developer sprint in Berlin, with the aim to give KMail a little boost. The sprint was hosted by KDAB and my employer (Kolab Systems) took care of my expenses, so there was nothing holding me from joining =)

While many concentrated on squashing KMail/Akonadi bugs I focused on yet another rewrite of the Akonadi-Nepomuk feeders, which are supposed to make the information stored in Akonadi available in Nepomuk.

Previously we had an agent for each mimetype, which made it difficult to control the resources which were used by the agents to index the data. To improve this situtation we decided on a plugin based architecture, where we can write plugins to index a certain mimetype, but the indexing is done by a single agent. This gives us a much better control of the used resources, so the indexing of the emails doesn’t bring down your whole system. It also allows us to index various items at different priorities. For instance the initial indexing of all your email (which can take rather long), has a lower priority than an item which you just changed. This is important so applications can rely on the feeder to bring changed items into nepomuk within reasonable time, so they are i.e. retrieved by fulltext search.

The first version already landed in master, but there are still some features of the old agent missing, such as the indexing of email attachments. However I think the new architecture is a real improvement over the old one and should give us a much better situation than before.

Just need to work out the last few kinks…

About these ads
This entry was posted in KDE. Bookmark the permalink.

7 Responses to PIM developer sprint

  1. Manolin says:

    Thanks for your work! the current feeder is using here around 2Gb of ram with an uptime of 48h so a rewrite seems in order to me :p also the new architurecture seems saner!

  2. Luis Silva says:

    Hi. I wanted to thank you and say how grateful I am for this work. I am a big pim application consumer and love the way things are going in kdepim world. I have been compiling and using kdepim (master) for a while now. I also got a few crashes (bug reported). How else can I help you guys debug and generaly improve the kdepim suit?

    • cmollekopf says:

      Hey, good to hear you like it =)
      Your reports already proved useful, so just go on like this =) Of course there is always lots to do, even if you’re not a developer yourself. There are tasks like updating documentation/wiki work, translations, bug triaging, etc. A helping hand is always welcome. However, providing useful bugreports and not creating duplicate bugreports already helps a lot =)

  3. Luis Silva says:

    Oh! And by the way, is anyone working on a tool to merge several contacts into one? Like the old merging tool in kaddressbook 3? With all my fiddling around I ended up with several instances of the same contact in each collection.

  4. Serafean says:

    This is great news! No more letting a useless computer run overnight to let it index a bunch of mails I imported… Big fan of kdepim.

    @Luis http://martys.typepad.com/blog/2011/08/gsoc-wrap-up-when-persons-go-into-a-library-aka-pimoperson-integration.html . Being worked on, with a slightly different approach :)

    • Luis says:

      @Serafean: I agree that for multiple calendars and when you want a representation of a person, that is the way to go (It doesn’t work at the moment, though). However, I want to physicaly merge the contacts in only one collection. Think of the situation where you have 3 vcard entries: “Jon Doe”, “Jon M. Doe” and “J. M. Doe”. They all represent the same contac but have different details in them. Now inamgine you want to send Jon Doe’s details to a friend. You need to merge the whole thing into a vcard first. What I was thinking is a tool that merges several akonadi:item’s into only one. Anyway, thanks for the link.

      • Well actually it wouldn’t be too hard to create a VCard out of the PIMO:Person. And you could even choose which data you’d like to put in the VCard. This is actually a pretty cool idea :)

        About the state of the project itself – the library is undergoing a major rewrite we designed at KDE-Telepathy sprint. Currently mostly George Goldberg is working on it as I’m too busy with uni work and also with our second release of KDE-Telepathy suite. The rewrite is rather complicated but I’m really excited about it and looking forward to work with this shiny new library. So just hold on ;)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s