<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Greetings,</p>
    <p>As you may know we have started working toward the integration of
      Lightning/Calendar into Thunderbird.  See this meta bug:
      <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1493008">https://bugzilla.mozilla.org/show_bug.cgi?id=1493008</a><br>
    </p>
    <p>Philipp, Magnus, Alessandro, and I have thoroughly discussed two
      possible options (system add-on and direct integration) while
      considering input from Geoff and others.  We have now decided on
      the direct integration option, with some guidelines for the
      handling of Calendar code.  This email is to announce the decision
      and share those guidelines, which are below.<br>
    </p>
    <p>The primary goal of these guidelines is to maintain the
      modularity of the Calendar code.  The guidelines should be clear
      (feel free to skip ahead and read them), but a concrete example
      may help to illustrate things.  Take menu integration, for
      example.  For a single Calendar menu item in a Thunderbird menu,
      it would make sense to just inline it in the Thunderbird UI file,
      using code comments and/or naming conventions to communicate that
      it is a calendar integration point.  For an entire menu or perhaps
      a menu item with many sub-menus, it would make sense for that UI
      code to be in a file in the calendar directory.  It could then be
      included in the Thunderbird UI code by using a preprocessor
      directive in the Thunderbird UI code.  Basically, smaller parts
      could be directly in-lined, and larger parts would stay in the
      calendar directory and be included by preprocessing.</p>
    <p>Any questions about any of this are welcome.</p>
    <p>Thanks,<br>
      -Paul<br>
    </p>
    <p>--------<br>
    </p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:3pt;"
      id="docs-internal-guid-54b5af55-7fff-133e-b19b-0f588885aa83"><span style="font-size:18pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">Guidelines for Calendar Integration in Thunderbird</span></p>
    <br>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">We will be transitioning Lightning/Calendar away from being an add-on so that it is, from the user’s perspective, just a part of Thunderbird.  Going forward, we will adopt these guidelines in order to maintain, at the level of code and from the programmer’s perspective, the modularity of Calendar as a separate component within Thunderbird.  The goal is to keep open the possibility of re-use of the calendar component/code, with minimal effort, in other ways or contexts in the future (e.g. a separate Calendar application), by not letting it become too coupled with Thunderbird code.</span></p>
    <br>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">To that end we will seek to maintain (e.g. in code reviews) a separation of concerns between Calendar’s (1) UI integration code, (2) core UI code, and (3) “business logic” code.</span></p>
    <br>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"
      role="presentation"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">1. UI Integration code should live in the calendar/ directory, but may be placed in other directories if necessary. Acceptable use cases include:</span></p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"
      role="presentation"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">    - Use of preprocessor defines to reference files in the calendar/ directory</span></p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"
      role="presentation"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">    - Single UI elements, properly identified as calendar items. For example using naming conventions (calendar-foobar-menuitem) 
</span></p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"
      role="presentation"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">2. Core UI code must live in the calendar directory.</span></p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"
      role="presentation"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">3. Business logic must live in the calendar directory as well.</span></p>
    <h2 dir="ltr"
      style="line-height:1.38;margin-top:18pt;margin-bottom:6pt;"><span style="font-size:16pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">Reviews</span></h2>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">Review of calendar code continues to require a peer of the calendar module. This includes larger chunks of calendar code outside of the calendar/ directory. To the contrary, use of preprocessor includes as well as similar use cases mentioned above don't require a calendar review.</span></p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">
</span></p>
    <p dir="ltr"
      style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">
</span></p>
  </body>
</html>