Closed Bug 378754 Opened 13 years ago Closed 11 years ago

Calendar Auto Configuration/Deployment

Categories

(Calendar :: General, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbo, Assigned: dbo)

References

Details

(Keywords: dev-doc-needed)

Attachments

(1 file)

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...
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...
Depends on: 403006
Blocks: 410287
Flags: wanted-calendar0.9+
No longer blocks: 410287
Duplicate of this bug: 331901
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: blocking-calendar1.0?
Attached patch patch - v1Splinter Review
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)
Flags: blocking-calendar1.0?
Keywords: qawanted
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).
Keywords: dev-doc-needed
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/b2cb2f44642f>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.