Jump to content

PIM/Meetings/Osnabrueck 7

From KDE Community Wiki
< PIM | Meetings
Revision as of 09:23, 10 January 2009 by Cornelius (talk | contribs) (→Agenda)

Annual KDE PIM meeting in Osnabrueck 2009.

Date: Jan 09th (friday) to Jan 11th (sunday).

Location/Travel

Location: NEW office of Intevation GmbH (Neuer Graben 17, 49074 Osnabrück, Germany), http://www.intevation.de/travel.en.html

Hotel: http://www.dom-hotel-osnabrueck.de/index_en.php (as usual)

Agenda

Unscheduled topics and corresponding responsible persons (feel free to remove yourself there if you don't like what I assigned to you ;-) ):

  • Porting strategy for KABC/KCal based resources and applications (Kevin, Tobias)
    • Designing an Akonadi-based replacement for KABC::StdAddressbook
  • Needed Akonadi developments for 4.3 (Volker)
  • Review Akonadi conflict detection (Stephen, Tobias, Volker)
    • detecting backend induced conflicts on the resource side
    • how to handle conflicts/GUI presentation
  • Re-Redesigned KMime ContentStrategy stuff using KJobs (still to do) (Stephen)
  • How to use Akonadi in your application/best practices/api dox review (Stephen)
  • Review Akonadi extensions currently developed in playground/pim (Stephen, Volker)
  • Review the distlist situation (Kevin, Tobias)
  • Bugzilla organization for Akonadi/KDE PIM (all)
  • Review of datastore.cpp in akonadi including possible refactoring and collectionMoved patch (Stephen, Volker)
  • Web pages (pim.kde.org, akonadi-project.org, techbase, userbase)
  • Group photo

Put topics you would like to discuss here

Tentative schedule:

Friday

All day: arrival

  • Forcing Ingo to finally commit his Akonadi work from the last meeting (Volker) ;-)
  • Evaluating the Akonadi migration in 4.2 or: the very last chance to stop Akonadi in 4.2 (Kevin, Volker)
  • KDE PIM runtime/apps split (Tom)
  • Discuss the fd.o situation (Cornelius)
  • Review Akonadi change notification (Stephen, Volker, Kevin, Tobias)

19:00 - 22:00 Dinner at "Chows Garten", Große Hamkenstr. 19

  • Free/Busy support (Brad, Will)
  • Consideration of moving mail output (i.e. kdepim/mailtransport functionality) to Akonadi (Brad, Will also curious)

Saturday

08:00 Breakfast

  • Presentation of the Akonadi on N810 project (Karim, Cédric, Romain, Audrey, Guillermo)
  • KMail porting strategy (Thomas, Till, Ingo, Volker, Stephen)
  • Static code analysis in KDE PIM (Bertjan)


19:00 Dinner at "Rampendahl", Hasestr. 35, http://www.rampendahl.de

Sunday

08:00 Breakfast

All afternoon: departure

BOFs

N810

  • David
  • Thorsten

Static call graphs with egypt

  • Thorsten

Meeting Notes

  • KResource -> Akonadi migration
    • disable the creation of KRes client side bridges, but leave the migration enabled as such.
  • Apps/Runtime split:
    • we will create a runtime subdirectory in kdepim containing runtime dependencies (akoandi agents, plugins, etc) which should be buildable separately, cf. kdebase
  • Akonadi MySQL dependency
    • Distributions need to put MySQL on KDE based install/liveCDs. It's size means there is less room for other KDE apps and other distro tools and dependencies.
    • The alternatives MySQL embedded and SQLite were rejected at proof of concept stage for different reasons: MySQL embedded does not handle transactions (doesn't have innoDB backend, which is the only one that supports real transactions), and is not as well supported by upstream for example the 64bit version is not well supported. SQLite is not fast enough for large amounts of data.
    • It might be possible to use Akonadi server with SQLite for example, the default will remain MySQL, but distros will possibly be able to use SQLite for CDs.
    • SQLite specific code still exists in kdesupport/akonadi/server, but needs to be updated as the schema may have changed since switching to use MySQL exclusively.
  • Review Akonadi change notification:
    • Adding ItemMoved and CollectionMoved and adding parent collection to {Collection,Item}Removed in a BC way.
    • Adding parent Collections to the slots itemChanged and collectionChanged was also discussed. The problem is that using a full path in a filesystem as a remoteId can be problematic if a collection higher in the heirarchy is renamed or moved. As a resolution, Items and Collections will both get a QStringList of ancestor collections and only use the filename or dir name as a remoteId instead of a full path. This is only of interest to Resources. Even some resources (eg with only one collection) will ignore it and use a full path.
    • If this gets built into Item and Collection, then this means that retrieveItem can remain BC and get this functionality anyway.
    • CollectionSync and ItemSync: Currently compare remoteIds. Will possibly need to be changed to also compare the heirarchy also. Remove assumption that no longer hold like remoteIds being unique over whole collection tree.
    • Ordering will remain in an attribute, and not be built into Collection. Ordering remains an application side configuration issue. Some aspects of this remain an open issue, such as ordering by applications before a remoteId gets generated for an item.
    • Adding ResourceBase::clearCache() to allow the resources to remove any previous cache content in case there configuration changed in a drastic ways. While this should mostly work currently already with the Item/CollectionSync stuff, there might be tricky corner cases if some remoteIds are reused.
  • Mailtransport with Exchange/Groupwise:
    • so far no agreement on an approach, several approaches discussed
    • mailtransport should not link against openchange etc.
    • use Ingo's outbox agent, items contain transport as attribute (or a separate outbox folder)
    • mailtransport could get an backend and dispatch mails to the exchange/groupwise resources that have the connection and account settings already
    • put mailtransport over dispatcher agent or other way around?
    • plugins for mailtransport instead all of the above, keeping the mime-level interface
    • depending on Akonadi and using items instead of mime objects
    • consider account setting duplications with resources
  • Invitations handling, Free/Busy handling, Delegation, (nested) distlists
    • same problem with exchange/groupwise as with mail sending, they use their own API for that
    • probably needs an abstraction layer
  • We want convenience API for the password handing, maybe based on Kopete's wallet password class, preferably built into KWallet or KConfigXT to deal with:
    • fallback to KConfig
    • password loading when wallet if opened by something else
    • notification when the password was loaded
    • async KConfigXT password support

Please complete by adding your notes!

Retrieved from "https://community.kde.org/index.php?title=PIM/Meetings/Osnabrueck_7&oldid=54126"