*KResource bridges: Using the old KResource API with the bridges causes some problems, thus all applications should be ported to the new Akonadi Contacts API

+

*KMailCVT: Porting to Akonadi is probably easy. We should get rid of the D-Bus interface to KMail and make it use Akonadi nativly. Target is KDE 4.5. In general, we want to remove all D-Bus controlled stuff and replace it with native Akonadi calls.

+

*KNotes: Will be replaced by KJots in the future

+

*KResources: Some KResources which have native Akonadi replacement can be removed. Others however are public API because they are in kdepimlibs

+

*Wizards: The idea is to use wizards with Kross scripting, so that custom providers can be added easily. That could even be integrated with KNewstuff. Volker has a prototype for this, just missing the servertest stuff.

+

*Akonadi KCM: Remove for KDE 4.4, not useful for most users, just confusing

+

+

Tom blogged about this [http://www.omat.nl/2009/10/17/akonadi-meeting-day-1-discussions-api-review/ here].

*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.

*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

+

+

<br>

+

+

*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.&nbsp;

+

+

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)&nbsp;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.

+

+

=== Mail filtering ===

+

+

General discussion of mail filtering capabilities and how to handle this.

+

+

There are three kinds of rules that we could think of:

+

+

*client rules. this isn't really in scope for akonadi (see also playground/pim/akonadi/filter for Szymon's GSoC on client side filtering)

Exchange rules can be set up to run on the client or server, or partly on both. Not yet clear how we can do the partly case - perhaps this would need to be a client-only rule.<br>

+

+

We didn't do a close comparison between what Sieve can do and what Exchange can do, however it appears difficult to share more than just a generic interface design. The problems we identified are that we'd need to be able to show the superset of all possible mail rule features (e.g. consider what happens if there is a rule created by another client that doesn't map properly into a hypothetic akonadi mail rules design).<br>

+

+

The initial plan is to add an class similar to Akonadi::TransportResourceBase (perhaps Akonadi::MailFilteringResourceBase) that a resource can inherit if it supports filtering.&nbsp; This might also require a change to the .desktop capability list.

+

+

We looked at Out-Of-Office handling as well. This is also needed for both Kolab and the openchange resource (and probably other groupware server resources). We can probably make this generic / shared.<br>

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€.

KResource bridges: Using the old KResource API with the bridges causes some problems, thus all applications should be ported to the new Akonadi Contacts API

KMailCVT: Porting to Akonadi is probably easy. We should get rid of the D-Bus interface to KMail and make it use Akonadi nativly. Target is KDE 4.5. In general, we want to remove all D-Bus controlled stuff and replace it with native Akonadi calls.

KNotes: Will be replaced by KJots in the future

KResources: Some KResources which have native Akonadi replacement can be removed. Others however are public API because they are in kdepimlibs

Wizards: The idea is to use wizards with Kross scripting, so that custom providers can be added easily. That could even be integrated with KNewstuff. Volker has a prototype for this, just missing the servertest stuff.

Akonadi KCM: Remove for KDE 4.4, not useful for most users, just confusing

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.

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.

Exchange rules can be set up to run on the client or server, or partly on both. Not yet clear how we can do the partly case - perhaps this would need to be a client-only rule.

We didn't do a close comparison between what Sieve can do and what Exchange can do, however it appears difficult to share more than just a generic interface design. The problems we identified are that we'd need to be able to show the superset of all possible mail rule features (e.g. consider what happens if there is a rule created by another client that doesn't map properly into a hypothetic akonadi mail rules design).

The initial plan is to add an class similar to Akonadi::TransportResourceBase (perhaps Akonadi::MailFilteringResourceBase) that a resource can inherit if it supports filtering. This might also require a change to the .desktop capability list.

We looked at Out-Of-Office handling as well. This is also needed for both Kolab and the openchange resource (and probably other groupware server resources). We can probably make this generic / shared.