KDE PIM/Meetings/Osnabrueck 7 - KDE Community Wiki

KDE PIM/Meetings/Osnabrueck 7 - KDE Community Wiki
Jump to content
From KDE Community Wiki
KDE PIM
Meetings
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),
Hotel:
(as usual)
Agenda
Friday
All day: arrival
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)
slides
Static code analysis/license issues in KDE PIM (Bertjan)
slides
Akonadi Promotion
KDE PIM on Windows/Mac OS
Group photo
Lunch
Porting KDE PIM to Akonadi - Planning for 4.3 and 4.4
19:00 Dinner at "Rampendahl", Hasestr. 35,
Review Akonadi extensions currently developed in playground/pim (Stephen, Volker)
Sunday
08:00 Breakfast
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)
FS backend
RID FETCH
Review the distlist situation (Kevin, Tobias)
KMail porting strategy (Thomas, Till, Ingo, Volker, Stephen)
Web pages (pim.kde.org, akonadi-project.org, techbase, userbase)
Lunch
Bugzilla organization for Akonadi/KDE PIM (all)
Review Akonadi conflict detection (Stephen, Tobias, Volker)
detecting backend induced conflicts on the resource side
how to handle conflicts/GUI presentation
How to use Akonadi in your application/best practices/api dox review (Stephen)
Review of datastore.cpp in akonadi including possible refactoring and collectionMoved patch (Stephen, Volker)
Forcing Ingo to finally commit his Akonadi work from the last meeting (Volker) ;-)
All afternoon: departure
BOFs
N810
David
Thorsten
are trying to
get the N810 kompile
Static call graphs with egypt
Thorsten
Meeting Notes
Akonadi, part one
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
KABC::StdAddressbook use-cases/replacements
insert/delete addressee: easily portable to jobs since result is usually ignored anyway
listing everything: usually not needed synchronously either, replace by item model
whoAmI(): usually needed synchronously, port to kpimidentities (which is sync since no Akonadi involved)
conflict handling
see discussion on kde-pim ml, it's largely what we came up here as well
before adding generic conflict handling code to libakonadi, we want to implement it in one application and resource first to confirm our design ideas.
multipart items and KABC::Addressee
there is no way to detect if an addressee object is incomplete (unlike with KMime, might need explicit API)
contact serializer plugin does not implement parts() and therefore always suppilies FullPart parts.
Akonadi server internal work
fix dataloss item/collection move/copy
fix change notification cross-resource moves
add change signal for collection moves
use changed parts parameter of itemChanged() (currently always emptry)
use the parts parameter of retrieveItem() (currently always empty)
remove the limitation that only resource can create top-level collections
Application Porting
kmail - biggest unit to be port
there are some plans for porting various components but no timelines.
pop
filtering
composer
mailtransport
header list
Apps currently using akonadi: mailody, kpilot
What resources exist for akonadi? Complete list is on akonadi-project.org(where?), but only vcardfile and icalfile resources are feature complete
kolab resource will be the biggest resource to write
imap resource: high performance imap library needed that supports all extensions. talking to pvhoof, maemo has a small fast imap lib already. Development of imap resource can be done in parallel with porting.
what do we need in 4.3. what can we achieve by 4.3? 6 month schedule, 4.3 will branch immediately before akademy
port kaddressbook and korganizer, everything but kmail for 4.3. replace kaddressbook with clean rewrite.
"We ported Kontact to Windows . We can do /anything/." TA
server-side search
limited api?
query language
operators
Web Site Meeting
Subject
web sites discussed:
techbase.kde.org
userbase.kde.org
community.kde.org - to be created
developer.kde.org
pim.kde.org
kontact.kde.org
wiki.kde.org
Participants
Cornelius
Ingo
Tom
Stephen
Thorsten
Summary
the community site
userbase.kde.org is for user questions like "how do I send a mail with kmail", techbase.kde.org is for technical questions like "how do I program a mail client". What is missing is a community web site for questions like "how do I create artwork for KDE PIM". This community web site should be a wiki. An idea is to create community.kde.org.
the to-be-created community page should have a structure like community.kde.org/PIM for the KDE PIM community. pim.kde.org should redirect there. If not "with slashes", the structure can be implemented using mediawiki categories.
the community site will at least hold events (like aKademy) and teams (like KDE PIM and the aKademy team)
it would be good to be able to have a different logo depending on what page realm you are in. E.g. you would get a KDE PIM logo for community.kde.org/PIM and a KDE GAMES logo for community.kde.org/GAMES.
this communities' correct name is KDE PIM, no hyphen, no dash. kdepim is the name of the KDE module.
redirects
wiki.kde.org is regarded as obsolete and ugly. It has been superseeded by techbase.kde.org and userbase.kde.org. wiki.kde.org should link to a web page that gives an overview to the visitor like "If you want to use KDE and have a question, go to userbase.kde.org. If you want to develop KDE, go to techbase.kde.org..."
developer.kde.org already links to techbase.kde.org. User pages like developer.kde.org/~username are not affected.
kontact.kde.org should redirect to userbase.kde.org/kontact
pim.kde.org should redirect to the new community wiki
translations
userbase.kde.org, no other site, must offer translations to other human languages than english. kontact.kde.org, the KDE PIM user page did not do this, but as KDE is shipped in other languages, the help should be available in those as well.
it could not be decided if the languages should get an own prefix (like de.userbase.kde.org), an own mediawiki namespace or a suffix like kmail_tutorial(german). So the situation stays as it is.
Todo
As outlined above, the following things should be done:
redirect wiki.kde.org to a site that links to userbase.kde.org and techbase.kde.org
redirect kontact.kde.org to userbase.kde.org/kontact
create a community wiki
redirect pim.kde.org to the community wiki
find a programmer who adapts mediawiki so the PIM pages (every module's pages) have their own logo
Please complete by adding your notes!
Blogs
Kevin Krammer: KDE PIM Meeting 2009 Preparations
Tom Albers: Random bits from Osnabruck: day 0+1
Till Adam: If you build it, they will come ...
Kevin Krammer: KDE PIM Meeting 2009 Debriefing
Tom Albers: Random bits from Osnabruck: day 1 + 2
Retrieved from "
Category
PIM