378754 - Calendar Auto Configuration/Deployment

Status: RESOLVED FIXED

(Calendar :: General, enhancement)

Description

[Daniel Boelzle [:dbo]]

Large deployments typically need auto configuration facilities. Regarding Sunbird/Lightning, this means auto configuration of users' calendars. Mozilla's auto configuration is commonly pref-based, see e.g. [1]. Similar to E-Mail accounts, I think of the following pref scheme:

STRING calendar.autoconf.calendars
  (comma separated list of cal-tokens)
BOOLEAN calendar.autoconf.only
  (optional, defaults to false,
   meaning all *non-autoconf'ed* calendars are unregistered/removed,
   i.e. only the autoconf ones are in place)
STRING calendar.autoconf.<cal-token>.uri
  (mandatory)
STRING calendar.autoconf.<cal-token>.type
  (mandatory)
STRING calendar.autoconf.<cal-token>.name
  (optional, defaults to uri.host)
STRING calendar.autoconf.<cal-token>.color
  (optional)
BOOLEAN calendar.autoconf.<cal-token>.visible
  (optional, defaults to true,
   meaning the calendar is pre-checked or not,
   technically whether in composite calendar or not)

e.g.
user_pref("calendar.autoconf.calendars", "cal1,cal2");
user_pref("calendar.autoconf.cal1.uri", "http://...ics");
user_pref("calendar.autoconf.cal1.type", "ics");
user_pref("calendar.autoconf.cal1.color", "#990000");
user_pref("calendar.autoconf.cal1.name", "ics cal");
user_pref("calendar.autoconf.cal2.uri", "https://...");
user_pref("calendar.autoconf.cal2.type", "wcap");

[1] <http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig>

Comments please...

Comment 1

[Daniel Boelzle [:dbo]]

I am asking myself why we should stick to storing the registered calendars in the storage.sdb. A fully pref-based registration would IMO avoid any further scheme for auto configuration (that I sketched above). Performance is IMO no problem; that data is read out once at startup, maybe listen to pref changes, but that's all.
Comments appreciated...

Comment 3

[Daniel Boelzle [:dbo]]

Attachment: patch - v1

With bug 403006 calendars could now be configured by pref.

This patch:
- changes calICompositeCalendar to not work by URI any longer
- calendar manager sanity checks the calendar.registry about stale entries (-> autoconf changes)
- fixes wcap subscription handling:
  -- if uuid changes, all subscriptions are reinstalled
  -- if default calendar's URI changes, subscribed URIs are corrected

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 356069 [details] [diff] [review]
patch - v1

Patch looks good, nothing to complain about :-)

r=philipp

Comment 5

[Daniel Boelzle [:dbo]]

For reference: Configuring a calendar is possibly e.g.

calendars.<id>.name
calendars.<id>.type
calendars.<id>.uri

W.r.t. type "wcap", this is the registration of the "default" calendar of a user. Subscribed calendars of that users will be registered on first startup. Changing the uri of this "default" section (e.g. admin decided to move accounts to a different machine) will patch all uris of subscribed calendars. Changing the id will remove formerly subscribed calendars and reinstall them (e.g. on changing user id).

Comment 6

[Daniel Boelzle [:dbo]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/b2cb2f44642f>

-> FIXED