docs/masters/conclusion.tex

   1 % vim: spelllang=en spell textwidth=120
   2 \documentclass[trojita]{subfiles}
   3
   4 \begin{document}
   5
   6 \chapter{Conclusion}
   7 \label{sec:conclusion}
   8
   9 The goal of this thesis was to investigate the existing IMAP extensions, evaluate how well they contribute to the
  10 operation of a mobile e-mail client, and find out what areas could benefit from further optimization.  All of these
  11 goals were fulfilled.
  12
  13 The ``mobile client'' I often speak about throughout this thesis is today a very powerful device, and one that is very,
  14 very different from what was considered a ``mobile client'' just a few years ago.  An ordinary phone that people use on
  15 a daily basis has typically a 1~GHz CPU with a gigabyte of RAM and can transfer data at the rate of several tens of
  16 megabits per second.  However, should these powerful resources be fully utilized, the battery life would drop to mere
  17 hours at best.  With great power comes great responsibility, and in the context of mobile applications this
  18 responsibility directly translates to a need of eliminating data transfers and CPU-heavy client-side operations as much
  19 as possible.  Thankfully, the IMAP protocol and its rich extension family provide ample opportunities for delegating a
  20 fair amount of processing to the server.
  21
  22 The available IMAP extensions range from simple tweaks of the protocol behavior and experimental facilities adding
  23 completely different features to IMAP all the way to the extensions which are hard to implement, but provide the
  24 protocol speakers with features or processes which would otherwise not be achievable, or prove to be needlessly hard to
  25 attain.  Certain features, formerly designed to accommodate hardware designs which are ancient through today's optics
  26 (like the support for command pipelining which was meant to allow the computer operators to physically locate a tape in
  27 their archive and mount that on the user's behalf), are today crucial for sustaining high performance over cellular
  28 networks with rather big round-trip times.
  29
  30 I believe that one cannot really evaluate a proposal without getting a perfect grasp of the changes it introduces.  This
  31 is why I implemented most of the available extensions in Trojitá, my free software project dedicated to building a
  32 usable, fast and lightweight IMAP e-mail client.  Functions which remained cumbersome or still required substantial data
  33 transfers even after the support for the existing extensions was added proved to be excellent candidates for proposing
  34 concrete enhancements.
  35
  36 I have selected three areas in which the IMAP protocol can be still improved.  These areas do not have much in common.
  37 It was my intention to demonstrate that even more than twenty years after the IMAP protocol was conceived, it can be
  38 still built upon and modified to better suit today's needs, and that these opportunities can be discovered on multiple
  39 fronts.
  40
  41 As an example of a rather low-hanging fruit, I have proposed an extension which fixes a possible race condition in the
  42 QRESYNC extension.  This bug illustrates the process of the protocol design pretty well --- despite a concerted effort
  43 of many people involved in drafting and reviewing of the proposal, bugs can still creep in.
  44
  45 A second extension which I have included in this thesis optimizes the behavior of an online client.  By building on top
  46 of three separate extensions which have been around for years, it allows an IMAP client to obtain threading information
  47 for messages in an incremental manner, preventing downloads of huge amount of data over and over again.
  48
  49 My last proposal deals with a relatively hot topic in the IMAP sphere --- it adds a support for message submission to
  50 happen over IMAP.  The question about whether this approach is the correct one has historically divided the protocol
  51 experts and software vendors into two hostile camps, one with cheering proponents, the other holding vigorous critics.
  52 People have tried to achieve a similar result by various means, but so far nothing as simple as the proposed {\tt UID
  53 SENDMAIL} has ever got enough traction.
  54
  55 All of the extensions which I have designed were submitted for review to the expert group through mailing lists related
  56 to the IMAP protocol and its extensions.  Especially with the last proposal, an interesting discussion has been sprouted.
  57 It will be interesting to watch the fate of the proposals as they enter the IETF standardization process.  With luck and
  58 enough patience, they might even become an RFC one day.
  59
  60 The Trojitá application has received a substantial amount of attention throughout my work on this thesis.  The project
  61 has grown almost three times in its overall size since my bachelor thesis on this subject.  I was happy to receive
  62 contributions from people all over the world.  Two companies expressed their interest in basing their commercial
  63 offering on top of Trojitá; I was hired to perform a contracted work on Trojitá on their behalf.  A completely new
  64 version of the user interface optimized for touch-controlled cell phones has been developed and --- thanks to a generous
  65 donation from Nokia --- ported to the MeeGo line of smartphones.  Interoperability testing revealed quite a few bugs,
  66 both in Trojitá as well as in production releases of IMAP servers from many software vendors, opensource and proprietary
  67 variants alike.
  68
  69 \section{Future Work}
  70 \label{sec:future-work}
  71
  72 This thesis represents the result of my ongoing involvement with IMAP and e-mail related topics in general.  It is my
  73 intention to carry on this work in future.
  74
  75 The documents I proposed will have to be maintained.  People known in the IMAP world have already raised their questions
  76 and provided valuable comments on the functionality of the extensions, some of them expressed explicit interest and
  77 willingness to implement them in their own products.  I will do my best to shepherd the drafts through their long
  78 journey towards possible acceptance.  Even if this process fails and no RFC gets directly produced, the approach will
  79 still have been documented and available for future protocol engineers and developers.
  80
  81 The Trojitá as a free software project will certainly benefit from its increased visibility.  There is a long list of
  82 features which might be added in future, be it support for signed or encrypted e-mails or pushing harder for
  83 implementation of more extensions among the IMAP servers.  The mobile version could certainly be ported to other phone
  84 platforms as well.  Targeting Android will definitely be a welcome improvement.
  85
  86 Some of the extensions which are mentioned in this thesis were not implemented in Trojitá for various reasons, typically
  87 due to the fact that I was not able to find any servers announcing their availability.  This should change in future ---
  88 some of the IMAP server vendors have already expressed their interest in implementing quite a few of these advanced
  89 features.  Thanks to its internal structure, I am confident that Trojitá will be able to accommodate these new proposals
  90 as they arrive.
  91
  92 \end{document}