Projects/PIM/Akonadi/Meeting2009-10 - Revision history

Tampakrap: Add my meeting notes, only one month late.

2009-11-20T19:50:14Z

Add my meeting notes, only one month late.

Vkrause: /* Mail filtering */

2009-10-18T14:21:45Z

‎Mail filtering

Bhards: /* Mail filtering */

2009-10-18T14:16:30Z

‎Mail filtering

Bhards at 10:18, 18 October 2009

2009-10-18T10:18:30Z

Bhards: /* Handling large address books */

2009-10-18T10:12:45Z

‎Handling large address books

Bhards: /* Meeting Notes */

2009-10-18T09:39:18Z

‎Meeting Notes

Vkrause: /* Agenda */

2009-10-18T08:45:52Z

‎Agenda

Vkrause: /* Sunday */

2009-10-18T08:44:14Z

‎Sunday

Vkrause: /* StandardActionManager redesign */

2009-10-18T08:29:14Z

‎StandardActionManager redesign

Vkrause: /* Meeting Notes */

2009-10-18T07:36:23Z

‎Meeting Notes

@@ Line 220: / Line 220: @@
 === Porting status / release planning / app/runtime split  ===
-TODO: Thomas
+*KOrganizer: Not ready for KDE 4.4
 === Akonadi/Nepomuk/Search and the future  ===

@@ Line 292: / Line 292: @@
 There are three kinds of rules that we could think of:
-*client rules. this isn't really in scope for akonadi<br>
+*client rules. this isn't really in scope for akonadi (see also playground/pim/akonadi/filter for Szymon's GSoC on client side filtering)
 *Sieve ([http://tools.ietf.org/html/rfc5228 tools.ietf.org/html/rfc5228]) server-side filtering using Cyrus IMAP&nbsp;server (for Kolab resource)<br>
 *Openchange / exchange server-side filtering ([http://msdn.microsoft.com/en-us/library/cc307725.aspx msdn.microsoft.com/en-us/library/cc307725.aspx]) for the openchange resource<br>

@@ Line 288: / Line 288: @@
 === Mail filtering  ===
-Things to discuss:
+General discussion of mail filtering capabilities and how to handle this.
-*any ability to share? is there anything other than sieve and openchange filtering we should consider?
+There are three kinds of rules that we could think of:
-*just create a "bool canDoFiltering()" and "void showFilterSetupDialog()"?
-*do we need anything else like this? a more general solution?
+*client rules. this isn't really in scope for akonadi<br>
 [[Category:Akonadi]] [[Category:PIM]]

@@ Line 216: / Line 216: @@
 * Hacking
-== Meeting Notes ==
+== Meeting Notes  ==
-=== Porting status / release planning / app/runtime split ===
+=== Porting status / release planning / app/runtime split  ===
 TODO: Thomas
-=== Akonadi/Nepomuk/Search and the future ===
+=== 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.
+Attending: Volker, Steve, Sebastian Trueg, Will Stephenson, Kevin Ervin
-** 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 ===
+*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.
-* Have a central generic action manager in libakonadi which propagates selection model changes and selection changes to special action managers for type specific actions.
+=== StandardActionManager (SAM) redesign  ===
-* 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:
+<br>
 ** 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
+*New design:
-** Allow inheriting operations from QUndoCommand and let SAM push them onto a QUndoStack
+**Separate action (the visual and state part) and operation (a single instance of an executed action)
-** Allow to register custom action/operations with SAM
+**Use prototype pattern for operations, which allows to customize them
-** 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
+**Allow inheriting operations from QUndoCommand and let SAM push them onto a QUndoStack
-** Keep visual/state updates in SAM and don't mix them with operation objects.
+**Allow to register custom action/operations with SAM
 === Handling large address books  ===
@@ Line 283: / Line 285: @@
 *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.
 [[Category:Akonadi]] [[Category:PIM]]

@@ Line 263: / Line 263: @@
 ** Keep visual/state updates in SAM and don't mix them with operation objects.
-=== Handling large address books ===
+=== Handling large address books  ===
 There was a quick discussion of large addressbooks.
-[[Category:Akonadi]]
+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).
 [[Category:PIM]]

@@ Line 195: / Line 195: @@
 * 20:00 Dinner
 * Hacking
@@ Line 206: / Line 208: @@
 * KMime API review
-* Free / busy management
+* Group photo
 * Hacking

@@ Line 200: / Line 200: @@
 === Sunday ===
-* 8:00 Begin
+* 8:30 Begin
 * KMime API review
 * Free / busy management
 * Hacking