This page is about the upcoming Akonadi Meeting in October 2009.
Date: October 16th (Friday) - October 18th (Sunday)
Location / Travel Information
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
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.
|| Accommodation needed
| Tobias König
|| 16th, around 16:00
|| 18th, around 17:30
| Thomas McGuire
|| 14th, around 17:00
|| 18th, around 15:00
| Tom Albers
|| 16th, around 16:00
| Dmitry Ivanov
|| 16th, around 12:00
|| 18th, around 15:00
| Andras Mantia
|| 14th, 17:05 TXL
|| 19th, morning
| Sebastian Trueg
|| 16th afternoon
|| 18th, ~ 18:00
|| yes (prefer not to share a room and will pay myself)
| Martin Koller
|| 16th around 12:30
|| 18th, ~ 18:00
| Sascha Peilicke
| Kevin Ottens
| Will Stephenson
|| 16th pm
| Brad Hards
|| train in, flight out
|| 16th around 13:30
|| 19th, 11:05 TXL
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]
- KMime [Diff]
- Akonadi Core [Diff]
- Akonadi Contact
- Akonadi KMime
- Kontact Interface
- Application porting status and planning, data and settings migration:
- 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?
- Free / busy management
- Mail Handling / Rules (Sieve, etc)
- StandardActionManager redesign (to support multiple views and extensibility)
- Do PIM applications still need to be KUniqueApplications?
- 18:00 Porting status and planning, module organization etc.
- 22:00 API review Akonadi Core library
- 10:00 API review libakonadi and mailtransport
- 13:00 Nepomuk integration
- 15:30 API review Akonadi contact library
- 23:00 OpenChange demo, free/busy abstraction, mail filtering abstraction
Porting status / release planning / app/runtime split
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.
Handling large address books
There was a quick discussion of large addressbooks.
There is a general problem with very large address books. An example is something like a company wide (global) address book. This will probably affect LDAP based address books (e.g. Kolab resource) and Exchange-based address books (e.g. openchange resource).
The scale of the problem is address books with potentially hundreds of thousands of entries. They could be a mixture of user addresses and distribution lists in a flat list.
For Akonadi to handle this properly, we need a few thing:
- We need a way to query all the address books for the information the user is looking for. Consider that the user may want to search the address book for users who's surname starts with Mac or Mc, or who's first name is Bob or Robert. Or some combination.
- We need a way to merge the results from various address books to present them to the user.
- We need to be able to avoid downloading / caching the whole global address book inside the Akonadi cache.
- We need to be able to page results from the resources. So if you have a dialog showing the global address list (with say 400 thousand entries), we don't need to download 200 thousand entries before you repaint the dialog contents. If the user scrolls down a bit, we ideally don't want to reload the bits that are the same.
Those requirements lead to some akonadi features we need to add:
- We need a caching policy that says "don't cache any of this". This would be particularly useful if we ever handle the Exchange offline address book.
- We need a (abstract) query language that gives resources enough flexibility to either allow searching / filtering on the server (whenever we can) or resource side (where we have to, or there is no server). It might be that the client needs to do some additional filtering.
- We need to have a consistent approach to showing global address books. Perhaps always showing it as a separate Collection would be useful to avoid resync operations.
Things to discuss:
- any ability to share? is there anything other than sieve and openchange filtering we should consider?
- just create a "bool canDoFiltering()" and "void showFilterSetupDialog()"?
- do we need anything else like this? a more general solution?