Calendar:Enterprise Features

<<Back to Features

This document outlines the technical details involved regarding the enterprise features planned for the calendar project, see Calendar:Status_Meetings:2006-07-19 for some background on this topic.

Technical details

The basic idea is to introduce a new folder structure beneath /calendar which contains the enterprise features which will be part of the regular builds. Those features are switched off by a hidden preference setting. The required folder structure is intented to look like this:

  /calendar
    /prototypes
      /wcap
      /themes
        /*instripe
    /locales
      /en-US
        /chrome
          /prototypes

As a first step the proposed new eventdialog Calendar:Event_Dialog will be put in /calendar/prototypes/wcap. Other features will be added as they come up. Since we already agreed that the typical review cycle makes no sense as the changes do not show up in regular installations, the proposed workflow is to simply check-in changes without filing bugs and submitting patches. This should not be understood as a permanent solution since those features added beneath the enterprise folder could serve as an experimental area where stuff could move to the regular core after they've been widely accepted and shown to be sufficiently mature.

Hidden Preference setting

I would propose to introduce the following preference setting which will be used to switch the enterprise features on and off. For example, the eventdialog would use different chrome-url's depending on the state of the enterprise-setting. The same mechanism could be used for other features that live in the enterprise folder as well.

  pref("calendar.prototypes.wcap", true);

Core changes

Certainly we'll need some minor modifications to the existing calendar code in order to make use of the enterprise features. As far as those modifications are driven by the enterprise switch it boils down to evaluate the setting and switch between the available implementations (default vs enterprise). Of course patches that enable different parts of the enterprise features will be filed as separate bugs. Another key benefit of this new experimental area will be the fact that we most probably will recognize code areas or interfaces that need to be generalized during development. This will help other contributors to plug-in new features easily as well.

Chrome packages

In order to make the additional files part of the regular builds we need to add them to the appropriate jar.mn-files. Those files will be read from the enterprise folder but will be stored besides the regular calendar files, for example in /calendar.jar/content/calendar. This makes it necessary to ensure that the files introduced beneath the enterprise folder have unique names. This solution painlessly makes the enterprise files invisibly part of the regular build.

Conclusion

This proposal outlines the technical details necessary to introduce additional features to the calendar project, as discussed in yesterday's weekly meeting. As always, comments are welcome.