Difference between revisions of "Projects/PIM/Akonadi/Meeting2009-04"

Latest revision as of 09:14, 10 April 2009

This page is about the Akonadi Meeting in April 2009.

Date: April 3rd (Friday) - April 5th (Sunday)

[edit] Location/links:

• Hotel & Office on Google Maps
• Subway and rail map of Berlin

KDAB
Adalbertstrasse 7/8
10999 Berlin
Germany

[edit] Agenda

• Resolve the POP3 agent/resource design disagreement
• Do we need to set some standards of compliance for names of Payload parts? Considering not all resources from third parties will use our stuff (KABC etc) we need to make sure they use the same names for payload parts.
• Should Monitor be configurable to watch {un,}subscribed collections?
• Do we need a way to know what payload parts are available to an item (or is it possible) or a bool Item::hasFullPayload()?

[edit] Friday

• Investigate the Lionmail performance issue
• User feedback
• Searching
• How should virtual collections/linking be handled? (thread) Open issues include
  • whether it should be possible to have both real items and linked items in one collection. If it was allowed it could take away difficult tasks like determining if a collection is virtual (currently hardcoded with search resource identifier in collectionutils_p.h).
  • how to determine if a user operation such as moves are permitted to/from the collection (possibly using collection rights).
  • Should list jobs fetch linked items or should that be configurable in the job?
  • Figure out use cases for virtual collections. Current ones include search collections, nepomuk tagging, 'single inbox'. The tagging and inbox idea are probably just specialized searches anyway.
  • Should it be possible to link collections as well as items?
  • Should it be possible to cascade virtual collections? (nepomuk tag trees say yes). This is possibly a non issue because there is actually nothing virtual about virtual collections. It could be a regular collection tree which happens to contain no real items and only links to items.
• Progress on implementing move support in akonadi. (thread)
• Can we have a recursive version of contentMimeTypes? (needed by entityTreeModel and could make filtering more sensible)
• How should statistics work and what information should they give? They should show counts of a particular mimetype in a collection, not just total count. Possibly also counts of items with a particular flag or attribute (new, watched important etc). eg, int CollectionStatistics::countMimetype(const QString &mimeType ), int CollectionStatistics::countAttribute(Akonadi::Attribute attr, const QString &mimeType= QString()), int countFlags(Akonadi::Item::Flags flags, const QString &mimeTypes), (etc?)

[edit] Saturday

• IMAP/Kolab resource design
• Mail part splitting
• KAddressbook vs. KContactManager
• KOrganizer porting
• Foosball

[edit] Sunday

• GSoC selection
• Group photo

[edit] Meeting Notes

[edit] Lion Mail (Sebastian)

• Lion Mail speed problem: Don't download the entire Gmane server in the background helps with that ;-)
• Sebastian demo'ed Lion Mail and told us his vision
• Sebastian would like to do queries like "the most recent 20 messages in collection foo". This requires searching/querying in Akonadi.
• For Lion Mail Sebastian wrote a few nice Plasma "widgets". We discussed that in order to share those "widgets" with other non-Plasma apps it would be preferable to implement those "widgets" as QWidgets and embed those into Plasma's canvas instead of adding a canvas to all apps that might want to use the "widgets".

[edit] Akregator/Akonadi RSS resource (Dmitry)

• See RSS framework for Akonadi.
• Dmitry wrote an RSS library for Akonadi
• Dmitry pointed out a few problems he noticed when using Akonadi (already added to Akonadi TODO list):
  • An ItemLinkJob was missing when he was working on his GSoC project (it's implemented now)
  • Searching is missing.
  • ResourceBase is limited to one job at a time; Volker pointed out that ResourceBase is convenience API and that concurrent jobs are possible on the lower API level
  • Batch jobs would be nice (e.g. for expiration, mark all as read, etc.); again this is already possible to some extend, but an easy to use client-side API is missing.

[edit] New Entity Model (Stephen)

• Stephen presented his entity model (replacement for the separate collection model and item model)
• The old collection model and the old item model can be realised as proxy models
• The model supports lazy loading.
• Linking is not yet implemented.
• Good API documentation is available.
• Currently the model lives in http://websvn.kde.org/trunk/playground/pim/akonadi/akonadi_next.
• We decided to move the model to kdepim/libkdepim and use it in the Akonadi ports of KOrganizer and the KDE Address Book. When it has stabilized it will be moved to kdepimlibs.
• Stephen also extended the QAbstractItemModel by methods for moving items in the model. This might be useful in general.

[edit] Searching

• Unfortunately, Sebastian Trueg could not make it.
• For local search SPARQL + Nepomuk seems to be the way to go.
• We identified two problems were Nepomuk does not help:
  • Server-side search (e.g. for LDAP, IMAP, etc.)
  • Incomplete data (e.g. encrypted mail)
• After some discussion we decided to add two APIs for searching:
  • One API using SPARQL+Nepomuk for complex (local) searches.
  • Another API using the more simple XESAM for more simple (key/value-style) searches including server-side searches.
    • Reasoning: Server-side searches (i.e. LDAP and IMAP) can be modelled with XESAM. The transformation from a XESAM query to an LDAP/IMAP query is much easier than the transformation of a SPARQL query.
    • email address completion (local + LDAP)
    • search all messages (local + IMAP)
    • quicksearch/filter messages (local + IMAP)
    • searches for calendar (all events for this week)
• With respect to the "search on incomplete data" problem we did not come up with a good solution. The problem is that Nepomuk has no way of knowing that it does not have all necessary data.

[edit] Virtual collections

• We went over the list of questions Stephen added to the agenda.
• We decided that we will add a way to identify virtual collections.
• Virtual collections and non-virtual (physical) collections will not be mixed, i.e. it will not be possible to put a linked item into a physical collection.
• We identified the need for hidden internal collections, i.e. collections that are used internally for queries or for chaining of agents, but that should not appear in the UI.
• Mime type(s) contained in virtual collections shall be updated immediately when adding new items; since updating this information on deletion of items is much more expensive this updating shall not be done immediately
• Whether a user operation such as a move is permitted to/from the collection shall be determined by the permissions of collections (write/change/read-only).

[edit] IMAP/Kolab resource design

• Use separate resources for IMAP and Kolab/Scalix
• Implement Kolab/Scalix as proxy resources, which map IMAP source items to groupware items.
• Advantages:
  • avoids duplication of IMAP resource code for Kolab/Scalix
  • separates Kolab/Scalix code from generic IMAP stuff
  • still allows access to the raw IMAP messages for testing/debugging
  • allows separate testing of Kolab code by eg. using a local maildir as source
• Disadvantages:
  • Slight overhead on the resource side

[edit] KAddressbook vs. KContactManager

• Tobias estimates the work needed to complete KContactManager (ie. be feature equivalent to KAddressbook) to be 1-2 weeks fulltime, in which case going for KContactManager is the obvious decision
• We could ship both for 4.3, is KContactManager is not yet a feature-equivalent replacement, and drop KAddressbook for 4.4

[edit] KOrganizer porting

• Solving the recurrence scalability problem:
  • Create a dedicate search provider for incidence time spans
  • In there, use a time line index based on expanded recurrences for a sliding time window.
  • Query using the Akonadi server search infrastructure
  • Report results using virtual collection
  • Clients have to re-expand the recurrence of the items in the selected time interval, which is acceptable (more or less constant for increasing calendar sizes)

[edit] Blogs/Press

• PIM Hackers Boost Akonadi Into The Future (dot story)
• Kevin Krammer: Brazilian overlords
• Tom Albers: Akonadi meeting: day 1 and 2
• Sebastian Kügler: Akonadi Sprint in Berlin
• Tom Albers: Akonadi meeting: day 0