(→Handling large address books) |
|||
| Line 216: | Line 216: | ||
* Hacking | * Hacking | ||
| − | == Meeting Notes == | + | == Meeting Notes == |
| − | === Porting status / release planning / app/runtime split === | + | === Porting status / release planning / app/runtime split === |
| − | TODO: Thomas | + | 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. | |
| + | **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: | + | <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 |
| + | **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 === | === Handling large address books === | ||
| Line 283: | Line 285: | ||
*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 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. | *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 === | ||
| + | |||
| + | 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? | ||
[[Category:Akonadi]] [[Category:PIM]] | [[Category:Akonadi]] [[Category:PIM]] | ||
This page is about the upcoming Akonadi Meeting in October 2009.
Date: October 16th (Friday) - October 18th (Sunday)
Contents |
KDAB Adalbertstrasse 7/8 10999 Berlin Germany 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 ;-)
Getting there directly: Take the subway line U8 to "Kottbusser Tor".
Hotel Ibis Berlin City Ost An der Schillingbrucke 2 10243 Berlin Germany 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:
Please collect stuff you want to do/discuss here.
TODO: Thomas
Attending: Volker, Steve, Sebastian Trueg, Will Stephenson, Kevin Ervin
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:
Those requirements lead to some akonadi features we need to add:
Things to discuss:
KDE TechBase 