Akademy 2005 in Malaga yielded a number of important decisions
related to KDE4 and KDE PIM. These are explained below.

<h2>KDE-PIM BoF Minutes</h2>


<h4>Agenda:</h4>

<ul>
  <li>Porting to Qt4/KDE4</li>
  <li>Merging Branches</li>
  <li>Redesigns</li>
  <li>Syncing</li>
  <li>Groupware Server</li>
  <li>Messaging</li>
  <li>Offline Mode for KMail/etc</li>
  <li>Meetings</li>
  <li>Alliances</li>
  <li>Website</li>
  <li>Artists</li>
  <li>3.6</li>
  <li>3.5 usability emergency surgery</li>
</ul>

<h4>Porting to Qt4/KDE4</h4>

<ul>
  <li>Check diff between 3.5 branch port and trunk (Ingo)</li>
  <li>Copy 3.5 to trunk (danimo)</li>
  <li>Merge Getting things done (SoC), kalle and proko2 changes</li>
  <li>Open trunk for KDE4 development</li>
  <li>use kdelibs from before the restructuring of libs</li>
  <li>Goal: Do library mode, more kdepim libs tgo kdelibs</li>
  <li>Start now</li>
</ul>

<h4>Merging Branches</h4>

Existing branches:

<ul>
  <li>SoC branches</li>
  <ul>
    <li>Scripting (merge later)</li>
    <li>Getting things done (merge to trunk after copying)</li>
    <li>Living KDE (merge later)</li>
  </ul>
  <li>Proko2 (till needs to merge 2-3 patches)</li>
  <li>Kalle (no problem)</li>
  <li>OpenSync branch (no problem, merge later)</li>
  <li>KoPI branch (carefully migrate individual patches)</li>
  <li>Two porting strategies</li>
  <ul>
    <li>Tag of current kde libs and port pim based on this tag</li>
    <li>"Wildwest" based on current trunk (risky)</li>
    =&gt; we'll for now go with the tagged version, but want to switch later to
    seize the possiblity of taking influence in lib development</li>
  </ul>
</ul>

<h4>Redesign</h4>

<ul>
  <li>KResource</li>
  <li>libkabc (e.g. async loading)</li>
  <li>stabilize libkcal (Reinhold)</li>
  <li>General access to PIMdata between KDE PIM applications</li>
  <li>Design APIs (Cross-Desktop, Evo DS, etc., check Evolution IPC, maybe use DBUS)</li>
  <li>UI redesign for resources, multiple calenders</li>
</ul>

<h4>Syncing</h4>

<ul>
  <li>OpenSync meeting held before aKademy: Armin Bauer, Cornelius Schumacher,
    Holger Freyther and Tobias K&ouml;nig attended.</li>
  <li>Goal: make OpenSync standard on the Linux desktop</li>
  <li>OpenSync is the successor to MultiSync. They have separated the GUI and the backend.</li>
  <li>written in C and glib internally</li>
  <li>Results</li>
  <ul>
    <li>C++/Qt wrapper</li>
    <li>KDE GUI</li>
    <li>KDE PIM plugin (in branch)</li>
  </ul>
  <li>Existing Plugins</li>
  <ul>
    <li>File</li>
    <li>Palm</li>
    <li>SyncML</li>
  </ul>
  <li>"KDE is the best GUI implementation" (Cornelius)</li>
  <li>OpenSync is the way to go</li>
  <li>New KitcheSync will replace KitchenSync, KSync, Kandy (which will not be ported to trunk), and eventually KPilot</li>
  <li>Till says "make a fuss on the dot, send clear message that KDE has decided to move to OpenSync"</li>
  <li>Will asked "should we use OpenSync for syncing resources and groupware </li>
    servers" -- "No because specialized sync algorithms can do a better job, risk </li>
    of dataloss if the index is broken, however some features of OpenSync are </li>
    attractive, we should try to provide better groupware middleware and reduce </li>
    code duplication"</li>
</ul>

<h4>Groupware Servers</h4>

<ul>
  <li>Get rid of all of the half-working Exchange connectors, reason: we don't
  have either vendor support nor resources to do it properly, so better not
  support it. Still possible to readd it, if somebody commits to it fulltime.</li>
  <ul>
    <li>Result: Disable from compilation in 3.5, remove in 4.0</li>
  </ul>
  <li>Stress commercial support makes effective groupware resources possible.</li>
  <li>Concentrate on working resources</li>
</ul>

<h4>Messaging</h4>

<ul>
<li>IM, VoIP, other messaging important to KDE PIM</li>
<li>improve integration of messaging - kopete, kcall, etc</li>
<li>consider move of kopete to KDE PIM - consult kopete devs</li>
<li>reconsider KIMProxy design, esp. wrt DBUS and standardization</li>
<li>Will leads the way</li>
<li>Integrating Kopete into kdepim?</li>
</ul>

<h4>Offlinemode in KMail/etc.</h4>

<ul>
  <li>Abstraction of KMail backend</li>
  <li>General offline mode (multiple online modes)</li>
</ul>

<h4>Meetings</h4>

<ul>
  <li>Osnabrück 4 would be a great idea (Jan 06)</li>
  <li>Alternative: Chemnitz (March 06)</li>
  <li>Possibly: KDE-NL again</li>
  <li>probably no need for further meetings this year</li>
</ul>

<h4>Alliances</h4>

<ul>
  <li>raise awareness that KDE has strong commercial support</li>
  <li>PR for existing collaborations</li>
  <li>Joint announcements</li>
  <li>Get KDE PIM supporters into KDE e.V.</li>
</ul>

<h4>Wesite</h4>

<ul>
  <li>split into developer/community and user/promo site has succeeded.</li>
  <li>Need artists (ask inside Novell?, Will)</li>
  <li>Need webmaster (IRC? Users List?) (danimo)</li>
  <li>Direction is ok </li>
</ul>

<h4>Artists</h4>

<ul>
  <li>kde-artists doesn't seem to work for us</li>
  <li>Oxygen for 4.0</li>
  <li>Keep what we have for 3.5 (unless we can get something really better)</li>
</ul>

<h4>3.6</h4>

<ul>
  <li>KitchenSync release beginning nexr year (with OpenSync 1.0)</li>
  <li>SoC : GTD, maybe more</li>
  <li>Translations?</li>
  <li>Coordinate with other modules</li>
</ul>

<h4>3.5. usability emergency surgery</h4>

<ul>
  <li>Some small improvements (usability)</li>
  <ul>
    <li>Resource selector improvements needed in KOrganizer and KAB</li>
  </ul>
  <li>Talk to the usability people</li>
  <li>Fix mailloss bug (Online IMAP)</li>
  <li>Everyone: please look for things that are obviously horrible, </li>
    by starting a session with a clean .kde/</li>
</ul>