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. . 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");  <http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig> Comments please...
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...
Created attachment 356069 [details] [diff] [review] 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
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #356069 - Flags: review?(philipp)
Comment on attachment 356069 [details] [diff] [review] patch - v1 Patch looks good, nothing to complain about :-) r=philipp
Attachment #356069 - Flags: review?(philipp) → review+
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).
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/b2cb2f44642f> -> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
You need to log in before you can comment on or make changes to this bug.