home *** CD-ROM | disk | FTP | other *** search
/ DOS/V Power Report 2004 March / VPR0403.ISO / talks / 142 / paper.dkb < prev    next >
Encoding:
Extensible Markup Language  |  2003-09-18  |  21.0 KB  |  514 lines
  1. <?xml version="1.0" encoding="ISO-8859-1"?>
  2.  
  3. <article id="paper-142">
  4.   <articleinfo>
  5.     <title>The KDE Kroupware Client</title>
  6.     <author>
  7.       <firstname>Bo</firstname>
  8.       <surname>Thorsen</surname>
  9.     </author>
  10.     <copyright>
  11.       <year>2003</year>
  12.       <holder>LinuxTag e.V.</holder>
  13.     </copyright>
  14.     <mediaobject>
  15.       <imageobject>
  16.         <imagedata fileref="picture-142-01.gif" format="GIF"/>
  17.       </imageobject>
  18.     </mediaobject>
  19.   </articleinfo>
  20.  
  21. <section>
  22.   <title>Free Software in the BSI</title>
  23.  
  24.   <para>The Kroupware project is a development that Bundesamt fr
  25.     Sicherheit in der Informationstechnik (BSI) of the German government
  26.     contracted from a consortium of three companies - Intevation,
  27.     Erfrakon and Klar舁vdalens Datakonsult AB.</para>
  28.  
  29.   <para>The project has three parts:</para>
  30.  
  31.   <itemizedlist>
  32.     <listitem><para>A groupware server.</para></listitem>
  33.     <listitem><para>A KDE client.</para></listitem>
  34.     <listitem><para>Compatibility with Microsoft Outlook.</para></listitem>
  35.   </itemizedlist>
  36.  
  37.   <para>The server has been made by Erfrakon; the client by Klar舁vdalens
  38.     Datakonsult AB and Intevation handled project administration. Outlook
  39.     compatibility is a shared task between the parts.</para>
  40.  
  41.   <para>BSI wanted to do a move towards free software, both on the client
  42.     and on the server. Currently there are no solutions that provide this
  43.     completely, although several projects are close.</para>
  44.  
  45.   <para>The solution we presented them is not a new development per se, but
  46.     instead an integration of existing parts and projects. Building a
  47.     complete groupware solution is an incredibly large job, but by using the
  48.     existing parts, we were able to have a working prototype in less than
  49.     three weeks.</para>
  50. </section>
  51.  
  52. <section>
  53.   <title>The Kolab Server</title>
  54.  
  55.   <para>The server built by Erfrakon is a collection of free software
  56.     server parts that have been put together to form a complete
  57.     groupware server solution. On top of the parts, Erfrakon built a
  58.     web administration module.</para>
  59.  
  60.   <para>The server parts are:</para>
  61.  
  62.   <itemizedlist>
  63.     <listitem><para>Apache Web server</para></listitem>
  64.     <listitem><para>Postfix Mail server</para></listitem>
  65.     <listitem><para>Cyrus Imap server</para></listitem>
  66.     <listitem><para>OpenLDAP LDAP server</para></listitem>
  67.     <listitem><para>Proftpd FTP server</para></listitem>
  68.     <listitem><para>Sieve scripting</para></listitem>
  69.   </itemizedlist>
  70.  
  71.   <para>A couple of other parts were also used, but these are the main
  72.     ones.</para>
  73.  
  74.   <para>The webinterface they built is used to administrate these parts
  75.     in an integrated way. For example, adding a user will put the user
  76.     information in the addressbook supplied by the LDAP server, it will
  77.     make a directory for web access using webdavs (and ftp, if legacy
  78.     support is enabled), and so on. Screenshots of the user administration
  79.     is given below.</para>
  80.  
  81.   <para>
  82.     <inlinemediaobject>
  83.       <imageobject>
  84.         <imagedata fileref="picture-142-02.gif" format="GIF"/>
  85.       </imageobject>
  86.     </inlinemediaobject>
  87.     <inlinemediaobject>
  88.       <imageobject>
  89.         <imagedata fileref="picture-142-03.gif" format="GIF"/>
  90.       </imageobject>
  91.     </inlinemediaobject>
  92.   </para>
  93.  
  94.   <para>The webinterface also controls the entire server environment. It
  95.     is here one can en- or disable services, as shown in the next
  96.     screenshot.</para>
  97.  
  98.   <para>
  99.     <inlinemediaobject>
  100.       <imageobject>
  101.         <imagedata fileref="picture-142-04.gif" format="GIF"/>
  102.       </imageobject>
  103.     </inlinemediaobject>
  104.   </para>
  105.  
  106.   <para>As you can see in the screenshot, ftp is only used for Outlook
  107.     2000 compatibility. Using this old and insecure protocol is an
  108.     unfortunate necessity when maintainting compatibility with old
  109.     legacy software. There are also many places in the client where this
  110.     compatibility requirement have meant lots of sidestepping the normal
  111.     Outlook approximations to standards.</para>
  112.  
  113.   <para>To make Outlook work with the server, we are using the Bynari
  114.     plugin, that enables Outlook to use other servers than Microsoft
  115.     Exchange. This plugin is also used in other Kolab like servers.
  116.     Currently SuSE and Bynari provides commercial Exchange replacements
  117.     that provide functionality akin to Kolab. But Kolab is the only
  118.     free software server that does the job.</para>
  119.  
  120.   <para>I will not describe the server in more detail here, but instead
  121.     go over the parts as seen from the client view in the discussion
  122.     of this.</para>
  123.  
  124. </section>
  125.  
  126. <section>
  127.   <title>The KDE Kroupware Client</title>
  128.  
  129.   <para>Where the server parts were easy to determine (setting aside
  130.     discussions like which IMAP server should be used), the client was
  131.     potentially taken from a larger array of possibilities. Mozilla and
  132.     Evolution would be the two other solutions that would have been
  133.     fairly easy to get working with Kolab. Yet another possibility would
  134.     be to extend an existing webbased groupware solution, but none was
  135.     found to be stable enough.</para>
  136.  
  137.   <para>A KDE solution based on KMail was the one that was chosen. Among
  138.     the arguments for this was the ﾄgypten project that Intevation,
  139.     Klar舁vdalens Datakonsult AB and g10 Code implemented for BSI.
  140.     </para>
  141.  
  142.   <para>It was decided that the main userinterface would be to have the
  143.     KDE calendar application KOrganizer embedded in KMail. Additionally,
  144.     the KDE addressbook KAddressbook should be able to access the LDAP
  145.     addressbook in the Kolab server. We did not want to rename the
  146.     actual parts used, so by now we use KMail, KMKO (abbreviation of
  147.     KMail/KOrganizer) or the Kolab client as the term for the application.
  148.     </para>
  149.  
  150.   <para>The next screenshot shows the main user interface of the client.
  151.     </para>
  152.  
  153.   <para>
  154.     <inlinemediaobject>
  155.       <imageobject>
  156.         <imagedata fileref="picture-142-05.gif" format="GIF"/>
  157.       </imageobject>
  158.     </inlinemediaobject>
  159.   </para>
  160.  
  161.   <section>
  162.     <title>New KMail features</title>
  163.  
  164.     <para>Klar舁vdalens Datakonsult AB and Marc Mutz added a good list
  165.       of new features to KMail for the Kroupware project:</para>
  166.  
  167.     <itemizedlist>
  168.       <listitem><para>Disconnected IMAP</para></listitem>
  169.       <listitem><para>Message Disposition Notification</para></listitem>
  170.       <listitem><para>Automatic Resource Handling</para></listitem>
  171.       <listitem><para>IMAP resource backend</para></listitem>
  172.       <listitem><para>KOrganizer connectivity</para></listitem>
  173.     </itemizedlist>
  174.  
  175.     <para>In the next sections, I will describe each of these.</para>
  176.   </section>
  177.  
  178.   <section>
  179.     <title>The Disconnected IMAP account</title>
  180.  
  181.     <para>Disconnected IMAP - from here on dIMAP - is at the heart of
  182.       the Kroupware project, since all user info is stored in IMAP
  183.       folders on the server.</para>
  184.  
  185.     <para>dIMAP works by
  186.       synchronizing the IMAP server contents to the local disk. The
  187.       KMail user will after the sync work on the local cache, and upon
  188.       the next synchronization, all local changes will be uploaded to
  189.       the server before new mails are downloaded to the local cache. The
  190.       basic idea is that after the synchronization, the contents of the
  191.       server and the local cache are identical.</para>
  192.  
  193.     <para>The user benefits in this is that you do not have to be
  194.       online to go through the mail boxes. It is also an easy way to
  195.       make two machines have the same mail setup - for example your
  196.       workstation and a laptop.</para>
  197.  
  198.     <para>With the current IMAP implementation in KMail no local cache
  199.       is used which means the user must be online while going through
  200.       the mail boxes. The biggest user benefit in this is that you local
  201.       disk usage is almost zero - not a small benefit if you have
  202.       several gigabytes of email.</para>
  203.  
  204.     <para>The future work for dIMAP includes two enhancements:
  205.       Selecting a folders to be synchronized, and creating filters for
  206.       what will be synchronized. </para>
  207.  
  208.     <para>Folder selection have almost been implemented.
  209.     The idea here is that normally you won't
  210.     synchronize all folders - users often have old mail archives that
  211.     are not often changed.</para>
  212.  
  213.     <para>Synchronization filters is a setup where the user can select
  214.       parts of the folders that shouldn't be downloaded to the local
  215.       cache (unless explicitly told to do so). Examples include "Don't
  216.       cache mails larger than X kb", "Don't cache attachments" and
  217.       "Don't cache mails older than two months".</para>
  218.  
  219.     <para>Comparing the two IMAP implementations show that the current
  220.       IMAP implementation is almost the same as the behaviour you get
  221.       when using a dIMAP implementation with a sync filter set to "Don't
  222.       cache anything" and the user deleting the cache after reading a
  223.       mail. The current implementation is very handy in the situation
  224.       where users have very little disk space available. When this isn't
  225.       the case, the dIMAP implementation should prove more
  226.       userfriendly. </para>
  227.  
  228.     <para>dIMAP have one other big advantage over normal IMAP. With
  229.       this, it's possible to use KMails excellent mail filtering.</para>
  230.  
  231.     <para>The implementation of dIMAP is approaching a very stable
  232.       situation, but the HEAD implementation still experiences
  233.       crashes. Data loss haven't been seen in testing since november,
  234.       but the local cache has been seen to be confused. Advice to people
  235.       wanting to use dIMAP is to backup mails they really don't want to
  236.       loose. The implementation is definately stable enough for more
  237.       thorough testing so we can find the remaining bugs that are
  238.       there. Speed-wise, the implementation isn't as effective as it
  239.       could be. We have concentrated completely on stability and
  240.       sacrificed all speedups we could think of to make the
  241.       implementation as stable as it can be. The effect should be that
  242.       it's much more stable, but synchronization can take quite a long
  243.       time. Later work on this should yield big speedups in the
  244.       synchronization. </para>
  245.  
  246.     <para>dIMAP uses the normal KMail maildir for the local cache, so
  247.       technically, what we did was to make the synchronization code and
  248.       not touch the local storage. This means that the local cache is
  249.       just as stable as having normal local maildir folders. At a later
  250.       point we hope to decouple the account code completely from the
  251.       folder code, so the user can choose which type of folder he wants
  252.       as the local cache.</para>
  253.  
  254.     <para>In all KMail screenshots that are here, the folders in the
  255.       Kolab account are dIMAP folders. The folders under INBOX are the
  256.       private user folders. The folders under shared are shared between
  257.       groups of persons - shared folders are set up by the web admin 
  258.       module</para>
  259.   </section>
  260.  
  261.   <section>
  262.     <title>Message Disposition Notification</title>
  263.  
  264.     <para>MDNs - Message Disposition Notifications - are a
  265.       generalization of what is commonly called "read receipt". The
  266.       message author requests a disposition notification to be sent and
  267.       the receiver's mail program generates a reply from which the
  268.       author can learn what happened to his message. Common disposition
  269.       types include "displayed" (i.e. read), "deleted" and "dispatched"
  270.       (e.g. forwarded).</para>
  271.  
  272.     <para>In KMail you can request notification when people read the
  273.       mail you sent, and KMail can send notification when you read mail
  274.       sent to you with notification requests.</para>
  275.  
  276.     <para>The next screenshots show the dialog you get when opening
  277.       an MDN mail, and the returned mail.</para>
  278.  
  279.     <para>
  280.       <inlinemediaobject>
  281.         <imageobject>
  282.           <imagedata fileref="picture-142-06.gif" format="GIF"/>
  283.         </imageobject>
  284.       </inlinemediaobject>
  285.       <inlinemediaobject>
  286.         <imageobject>
  287.           <imagedata fileref="picture-142-07.gif" format="GIF"/>
  288.         </imageobject>
  289.       </inlinemediaobject>
  290.     </para>
  291.   </section>
  292.  
  293.   <section>
  294.     <title>Vacation setup</title>
  295.  
  296.     <para>You can now setup timeframes where you are away from a small
  297.       userfriendly dialog in KMail:</para>
  298.  
  299.     <para>
  300.       <inlinemediaobject>
  301.         <imageobject>
  302.           <imagedata fileref="picture-142-08.gif" format="GIF"/>
  303.         </imageobject>
  304.       </inlinemediaobject>
  305.     </para>
  306.   </section>
  307.  
  308.   <section>
  309.     <title>Automatic resource scheduling</title>
  310.  
  311.     <para>In groupware mode, you can setup accounts to work as
  312.       automatic resource scheduling. With this, you set up accounts for
  313.       each resource you want to schedule. An example could be a
  314.       room. You make an account that holds the rooms calendar, and
  315.       people "invite" the room to a meeting. When KMail receives such an
  316.       invitation, it automatically accepts if the resource is free - if
  317.       not, it rejects the invitation. We don't mind people calling this
  318.       a hack, but it works surprisingly well :-) </para>
  319.   </section>
  320.  
  321.   <section>
  322.     <title>IMAP Resource backend to KMail</title>
  323.  
  324.     <para>The new resource framework in kdelibs and kdepim have
  325.       different backend implementations. The obvious one is to use the
  326.       local disk for the storage, which is the standard
  327.       implementation. For the addressbook, there is also an LDAP
  328.       backend, and so on. </para>
  329.  
  330.     <para>We have implemented a resource backend in KMail, so this can
  331.       be used for storage. This means KOrganizer, KAddressbook and other
  332.       applications can save their data in KMail folders. This is
  333.       specifically done with dIMAP in mind, so synchronization in
  334.       addition to emails also syncs calendar, contacts and notes</para>
  335.   </section>
  336.  
  337.   <section>
  338.     <title>KOrganizer connectivity for groupware scheduling</title>
  339.  
  340.     <para>To complete the groupware functionality, code have been
  341.       added to KMail to intercept incoming groupware messages. </para>
  342.  
  343.     <para>In KMail, different things happen depending on what is in
  344.       the message currently being read. We have added the check for
  345.       mimetypes holding calendar related information. When a message
  346.       with such a mimetype is seen, the iCal file is given to the
  347.       groupware code that reformats it to a HTML message which includes
  348.       the choices the user has. So when an invitation arrives, this is
  349.       transformed to a message saying you have been invited to a meeting
  350.       in XX from YY to ZZ. Below that there are four links with
  351.       different options, the most important being accept and
  352.       decline. When the user clicks one of these links, KMail will call
  353.       KOrganizer code with the message and the user choice. After that
  354.       it is up to KOrganizer to put the information into the right
  355.       resource (which could be the IMAP resource as described
  356.       above). A screenshot of receiving an invitation is shown below.</para>
  357.  
  358.     <para>
  359.       <inlinemediaobject>
  360.         <imageobject>
  361.           <imagedata fileref="picture-142-09.gif" format="GIF"/>
  362.         </imageobject>
  363.       </inlinemediaobject>
  364.     </para>
  365.  
  366.     <para>In addition to this, KMail also offers to format and send
  367.       the messages from KOrganizer, so correct replies and invitations
  368.       are sent. More on this below.</para>
  369.  
  370.     <para>The general split here is that KOrganizer handles all iCal
  371.       related, and KMail handles how the iCal is put into mails or read
  372.       from mails. </para>
  373.   </section>
  374.  
  375.   <section>
  376.     <title>KOrganizer enhancements</title>
  377.  
  378.     <para>Klar舁vdalens Datakonsult AB also did the work on
  379.       KOrganizer and the underlying iCalendar libraries to make it
  380.       work with the Kolab server inside KMail.</para>
  381.  
  382.     <para>There were basically three things we had to do:</para>
  383.  
  384.     <itemizedlist>
  385.       <listitem><para>Enhance groupware scheduling</para></listitem>
  386.       <listitem><para>Enable IMAP (KMail) storage</para></listitem>
  387.       <listitem><para>Embed KOrganizer in KMail</para></listitem>
  388.     </itemizedlist>
  389.  
  390.     <para>KOrganizer already had a kind of groupware scheduling, but
  391.       it was missing several features. The most visible of these was
  392.       fixed with the addition of a gantt view in the invitation dialog.
  393.       A screenshot of this is given below.</para>
  394.  
  395.     <para>
  396.       <inlinemediaobject>
  397.         <imageobject>
  398.           <imagedata fileref="picture-142-10.gif" format="GIF"/>
  399.         </imageobject>
  400.       </inlinemediaobject>
  401.     </para>
  402.  
  403.     <para>In this screenshot, you can also see the list of people invited,
  404.       you have the action that these are expected to take, their roles,
  405.       and overview of who have answered what and so on. The gantt view
  406.       shows the schedule of each of the participants, with the red boxes
  407.       being the busy periods, and the purple vertical bar being the current
  408.       time of the meeting. The dialog can automatically find the next
  409.       time where all participants are free.</para>
  410.  
  411.     <para>KOrganizer is embedded in KMail using the KParts technology.
  412.       This is the component architecture in KDE that enables parts
  413.       containers to embed parts inside the user interface. Especially
  414.       Konqueror uses this extensively to show different file types.</para>
  415.  
  416.     <para>Not directly visible was all the work that was done on
  417.       KOrganizer and the kdepim libraries to make it work with KMail. This
  418.       work included answering KMail requests about iCalendar files;
  419.       constructing iTIP messages (iCalendar scheduling files) to be sent by
  420.       KMail; receiving appointment replies and updates; and using KMail IMAP
  421.       folders as the storage.</para>
  422.   </section>
  423.  
  424.   <section>
  425.     <title>Other Kdepim Components</title>
  426.  
  427.     <para>Two more applications needed some extra work - KPilot and
  428.       KAddressbook. Unlike KOrganizer, these continue to be separate
  429.       applications as opposed to run inside KMail.</para>
  430.  
  431.     <para>KPilot is the application that syncs calendar and addressbook
  432.       information to Palm Pilot handhelds. This needed to be modified
  433.       so it was also able to read everything from the KMail storage.</para>
  434.  
  435.     <para>KAddressbook also got that extra feature. In the Kolab
  436.       environment this has a special meaning. The shared addressbook is
  437.       shared using LDAP. The entries in the users own Contacts KMail folder
  438.       are private entries, where the user can add all contact information.
  439.       A screenshot of KAddressbook with some local contacts is shown below.
  440.       </para>
  441.  
  442.     <para>
  443.       <inlinemediaobject>
  444.         <imageobject>
  445.           <imagedata fileref="picture-142-11.gif" format="GIF"/>
  446.         </imageobject>
  447.       </inlinemediaobject>
  448.     </para>
  449.   </section>
  450. </section>
  451.  
  452. <section>
  453.   <title>Future Work</title>
  454.   <para>In kroupware_branch all this is working, but in cvs HEAD
  455.     there are still some issues to be sorted out before this is
  456.     working. The difference is that in kroupware_branch, all
  457.     communications is done with Qt signals and slots, where in HEAD
  458.     it's done with DCOP. This is currently being retrofitted to work
  459.     in the Kontact framework and is looking very promising. </para>
  460.  
  461.   <para>Kontact is better designed technically, and will hopefully also
  462.     be an even better user experience. Currently the KMail parts of
  463.     kroupware have been ported, and the IMAP resource backend have been
  464.     reimplemented in the new framework. The missing parts are the
  465.     korganizer parts that enable the groupware scheduling. This will
  466.     hopefully be done before KDE 3.2.</para>
  467.  
  468.   <para>A screenshot taken by Zack Rusin of Kontact:</para>
  469.  
  470.   <para>
  471.     <inlinemediaobject>
  472.       <imageobject>
  473.         <imagedata fileref="picture-142-12.gif" format="GIF"/>
  474.       </imageobject>
  475.     </inlinemediaobject>
  476.   </para>
  477.  
  478.   <para>Other future work is to implement a lot more groupware features.
  479.     The Kroupware project had a very specific list of features, and there
  480.     are plenty more features that we would like to implement.</para>
  481.  
  482.   <para>Another area is that we hope other projects will implement support
  483.     for the Kolab server and cooperation with the KDE client. A webbased
  484.     solution is currently in it's early beginning, and hopefully Evolution
  485.     and Mozilla people will work on this too.</para>
  486.  
  487. </section>
  488.  
  489. <section>
  490.   <title>Reference Links</title>
  491.   <para>The three companies that implemented the Kroupware Project:</para>
  492.   <itemizedlist>
  493.     <listitem><ulink url="http://www.klaralvdalens-datakonsult.se">Klar舁vdalens Datakonsult AB</ulink></listitem>
  494.     <listitem><ulink url="http://www.intevation.net">Intevation</ulink></listitem>
  495.     <listitem><ulink url="http://www.erfrakon.de">Erfrakon</ulink></listitem>
  496.   </itemizedlist>
  497.  
  498.   <para>The project and the KDE parts</para>
  499.   <itemizedlist>
  500.     <listitem><ulink url="http://www.kroupware.org">The Kroupware Project</ulink></listitem>
  501.     <listitem><ulink url="http://kmail.kde.org">KMail</ulink></listitem>
  502.     <listitem><ulink url="http://kdepim.kde.org">KDE PIM applications</ulink></listitem>
  503.     <listitem><ulink url="http://kmail.kde.org">KMail</ulink></listitem>
  504.     <listitem><ulink url="http://kontact.kde.org">Kontact</ulink></listitem>
  505.   </itemizedlist>
  506.  
  507.   <para>Other projects</para>
  508.   <itemizedlist>
  509.     <listitem><ulink url="http://www.gnupg.org/aegypten/">The ﾄgypten project</ulink></listitem>
  510.   </itemizedlist>
  511. </section>
  512.  
  513. </article>
  514.