< Projects‎ | PIM‎ | Akonadi
Revision as of 08:44, 18 October 2009 by Vkrause (Talk | contribs)

Jump to: navigation, search

This page is about the upcoming Akonadi Meeting in October 2009.

Date: October 16th (Friday) - October 18th (Sunday)


Location / Travel Information


Adalbertstrasse 7/8
10999 Berlin
Phone: +49-30-5213254-70

Getting there from the hotel: takes about 15 minutes to walk, just follow the others, most have been here already ;-)

Hotel -> Office map

Getting there directly: Take the subway line U8 to "Kottbusser Tor".

Subway and rail map of Berlin


Hotel Ibis Berlin City Ost
An der Schillingbrucke 2
10243 Berlin
Phone: (+49)30/257600 
Fax : (+49)30/25760333

Easiest way to reach the hotel is by taking a train to Ostbahnhof (it's just across the street from the station). If your train doesn't stop there, take the S-Bahn from Hauptbahnhof, any east-bound line will do.

From TXL take the bus labeld 'TXL' to Hauptbahnhof or Alexanderplatz and switch to the S-Bahn there, any east-bound train will do.

In both cases you'll need a single 'AB' Ticket, which can be purchased on ticket machines and costs 2.10€.


Non-locals, please add yourself, your travel details and accommodation needs to the following table.

Name Travel Arrival Departure Accommodation needed
Tobias König train 16th, around 16:00 18th, around 17:30 yes
Thomas McGuire train 14th, around 17:00 18th, around 15:00 yes
Tom Albers train 16th, around 16:00 18th yes
Dmitry Ivanov plane 16th, around 12:00 18th, around 15:00 no
Andras Mantia plane 14th, 17:05 TXL 19th, morning yes
Sebastian Trueg train 16th afternoon 18th, ~ 18:00 yes (prefer not to share a room and will pay myself)
Martin Koller plane 16th around 12:30 18th, ~ 18:00 yes
Sascha Peilicke train 16th 20th no
Kevin Ottens plane 11th 18th yes
Will Stephenson drive 16th pm 18th no
Brad Hards train in, flight out 16th around 13:30 19th, 11:05 TXL yes

Locals present anyway:

  • Bertjan Broeksema
  • Frank Osterfeld
  • Steve Kelly
  • Till Adam
  • Volker Krause


Please collect stuff you want to do/discuss here.

  • We have quite some new public API which needs to be reviewed, in the following libraries:
    • Mailtransport [Diff]
    • MessageViewer
    • KMime [Diff]
    • Akonadi Core [Diff]
    • Akonadi Contact
    • Akonadi KMime
    • Kontact Interface
  • Application porting status and planning, data and settings migration:
    • KMail
    • KOrganizer
    • Akregator
  • KDE PIM module organization
    • Fix apps/runtime split again
  • Nepomuk integration
    • Fix the usage of non-Fast resources in the feeder agents
    • Fix the feeders to behave according to Sebastian's email, and document the correct behavior somewhere
    • Avoid ontology duplication, move them to kdelibs or soprano maybe?
  • Extensions
    • Free / busy management
    • Mail Handling / Rules (Sieve, etc)
  • StandardActionManager redesign (to support multiple views and extensibility)
  • Do PIM applications still need to be KUniqueApplications?


  • Hacking
  • 18:00 Porting status and planning, module organization etc.
  • 19:00 Dinner
  • 22:00 API review Akonadi Core library


  • 08:15 Hacking
  • 10:00 API review libakonadi and mailtransport
  • 12:30 Lunch
  • 13:00 Nepomuk integration
  • 15:30 API review Akonadi contact library
  • 17:30 Hacking
  • 18:30 ETM API review
  • Hacking
  • 20:00 Dinner
  • Hacking


  • 8:30 Begin
  • 9:00 SAM redesign
  • KMime API review
  • Free / busy management
  • Hacking
  • 12:00 Lunch
  • Hacking

Meeting Notes

Porting status / release planning / app/runtime split

TODO: Thomas

Akonadi/Nepomuk/Search and the future

Attending: Volker, Steve, Sebastian Trueg, Will Stephenson, Kevin Ervin

  • Discussed future of desktop PIM and applications which are context or project specific rather than transport specific. Ie, beyond the concepts of "one application handles my email, another handles my contacts, another handles my notes." Instead these things should be grouped and available in applications which present them by project/task or person.
    • Should be able to clear completed tasks by taking action on them. For any task, there may be multiple action paths to complete before the task is "complete", eg "The cat just threw up. Clean up the mess. Take the cat to the vet". Two action paths to handle the sick cat.
  • Communicating with contacts independently of the transport mechanism in an application which can show history of communication with the person. Also, be able to configure notifications such as "Notify me the next time this person is online using the message 'Talk to Alice about the server backups'"
  • Merging of contacts from multiple resources.
    • Tricky because some resources have read-only access.
    • Some resources rewrite fields, which could mean bugs like having to perform a merge operation again and again.
    • Could be sensible to link Akonadi contacts to PIMO::Person objects in Nepomuk.
  • Considering the implementation of how tags should be represented in PIM apps.
    • Showing "All available tags from Nepomuk with linked items in the collections" would not scale because people could have thousands of, eg, emails, but only several would be relevant and contain tagged emails. It could be more sensible to configure individual simple searched such as "show me emails tagged with 'giraffe'" and use searches instead of explicitly using the tag resource.
    • Nepomuk triples can be queried in interesting unrestricted and versatile ways. predicates can be variables and can have placeholders.
    • Discussed the ideas brought out in Zeitgeist and how it can relate to Nepomuk and hooked into KIO.
  • How can PIM relate to plasma activities, for example?
    • Possible that PIM applications should not directly respond to changes in plasma activity, but plasma activity should map in some way to one or more 'PIMO::Project', and therefore change the most easily acceptible data related to the project.
  • Storing search index of encrypted emails in a second, encrypted rdf store.
    • Virtuoso has some useful stuff to make this possible, but it is preferable to create a model in the Soprano interface instead.
  • Synching two Nepomuk stores.
    • Possible to use a resource that represents remote nepomuk objects as akonadi Items and feed them into the local index.
    • Soprano needs to get some more api for that.
  • Separate but related is accessing a remote Akonadi server over ssh for example.

StandardActionManager (SAM) redesign

  • Have a central generic action manager in libakonadi which propagates selection model changes and selection changes to special action managers for type specific actions.
  • In case of multiple item views, have a way to select which one is active, most notably before showing a context menu on it.
  • We need customizing of operations, such as
    • FFV actions
    • anything using a mime type filter
  • We also need undo

  • New design:
    • Separate action (the visual and state part) and operation (a single instance of an executed action)
    • Use prototype pattern for operations, which allows to customize them
    • Allow inheriting operations from QUndoCommand and let SAM push them onto a QUndoStack
    • Allow to register custom action/operations with SAM
    • Put the most common state handling into SAM (mimetype, amount of selected objects, ACL), provide accessor methods for selection models and a updateState() signal for custom state handling
    • Keep visual/state updates in SAM and don't mix them with operation objects.

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal