API to reflect provider capabilities

RESOLVED FIXED in 0.8

Status

enhancement
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Fallen, Assigned: Fallen)

Tracking

(Blocks 1 bug)

unspecified
Dependency tree / graph

Details

(Whiteboard: [gdata-0.4])

Attachments

(3 attachments)

As discussed in the Hamburg F2F meeting, we need an abstract mechanism to check which capabilities a provider has. This could be implemented in calICalendarProvider. The following (probably incomplete) list shows *possible* capabilities that could be checked:

* Support certain calIEvent/calITodo features
  (Mainly needed for the event dialog. For many of these features it should
   also be possible to set up which values are accepted, I will mark those
   with a [DV]. Others where I am not sure are marked with [?])
  - [DV] Priority/Privacy
  - URL
  - [DV] Alarms 
  - [?] Can provider snooze events
  - [DV] Status
  - [?] Recurrence
  - Attachments (probably needs a more general solution anyway)
  - Attendees
* Providers ability to support Todo / Event items altogether
* How does provider handle timezones (probably deserves its own bug)
  (What happens if a provider only supports a subset of timezones? For example
   WCAP only has Europe/Paris, which is the same as Europe/Berlin, GData only
   uses timezone offsets (bad), but somehow maps to timezones in the ical feed)


See also http://wiki.mozilla.org/Calendar:Hamburg_F2F_Meeting
(Assignee)

Updated

12 years ago
Depends on: 297721
Target Milestone: --- → 1.0
I suggest to only add those a flag when we find that we need it. So work on an use-case basis, instead of adding a lot of stuff that might one day be needed.

Additional bonus is that updating the UI to actually use the flags is easier to do when done in steps. (and easier to review!)
I understand this bug the way, that we need to agree on general mechanism(s) for capabilities, regardless of what actual capabilities are to be defined in the IDL. Philipp stated "could be implemented in calICalendarProvider", so I changed the title accordingly.
I agree with mvl that the list of capabilities should grow over time and we shouldn't add API unless the front-end code actually uses it. But it makes sense to sort out what potential capabilities are coming up, so we can figure out the best mechanism.
Regarding value ranges, we should strongly stick to RFC2445, i.e. providers may translate values. IMO we can't allow different value ranges/semantics (e.g. provider A defines priorities 1..10 while provider B defines 0..99), because we run into trouble when migrating items between calendars. I would accept conversion loss in that area.
Other related bugs I have posted (with some work in progress patches) are bug 370146 (searching calendars), bug 370148 (free-busy).
Summary: Add provider capabilities to calICalendarProvider interface → API to reflect provider capabilities
I understand the concerns regarding different values, but let me throw up an example: Google now only support certain alarm values. To make this transparent to the user, I need a way to instruct the UI to only show a dropdown with these values. Of course there are Problems when migrating from a non-google calendar to a google calendar, but to me it doesn't sound right when you enter a random value, save the event, reopen it and then see that you have a totally different value. It would be better if this discrepancy happens when migrating calendars, then provider can transform.

Also another nice example is the "canceled" status. Google will mark the event as deleted. The only way to get those items back is to use the updated-min parameter, which also gives all conventionally deleted items. I need to remove this item from the dropdown. There are of course problems again when migrating from a calendar that has canceled items to the google calendar. I'm not sure what to do about that.

The only workaround I can think of in both cases (and some of those below) is to use x-props, but thats not very practical, at least in the first case.

To make a start of what I specifically need (If I don't revert to x-props):

- Discrete Values for alarms
- Hide the URL field
- Hide the priority field
- Remove the "canceled" status from the status dropdown
- Remove everything that has to do with tasks (i.e remove the event/task conversion)
W.r.t. the coming pref/properties API shift to the providers (a patch of bug 356569), I propose to model optional calendar capabilities as (transient read-only) properties, e.g.

if (calendar.getProperty("capabilities.supportsChangelog")) ...

I'd like to define a clear namespace for capabilities to avoid clashing with other calendar properties.
This patch provides an initial set of capability checks. I think  we should create new bugs for any further capabilities as time goes, otherwise this bug will be open forever ;)

This patch uses the format "capabilities.<foo>.supported" and "capabilities.<foo>.values" to allow providers to control the UI if one of its calenars is selected.

The fields I chose to start with are URL, priority and privacy. All fields implement the ".supported" check, while only privacy implements the ".values" check.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #295374 - Flags: review?(daniel.boelzle)
Christian, it would be great if you could provide me with an icon for the statusbar for the Google 'DEFAULT' privacy status, similar to the existing public/private/confidential icons.
Attachment #295375 - Flags: ui-review?(christian.jansen)
(Assignee)

Updated

12 years ago
Blocks: 401263

Comment 7

12 years ago
I'm asking myself, if we really need to display an icon. If so what should be displayed, an opened lock? IMO it makes most sense to show simply nothing. In addition I find the term "Default" not very sufficient. It is too unspecific, anyhow Google uses the same, so it is consistent ;-)

So here is what I propose:
- For "Default" display neither a icon nor a string in the Status bar
- For "Private" display the closed lock symbol
- For "Public" display opened lock symbol.

Does that make sense?
I agree, the term default is not really userfriendly. You are right, its probably better to leave the text and icon away for default. Do you think I should name the menu item "Google Default" instead of "Default", to make sure the user knows what the default is?

Comment 9

11 years ago
What about "Calendar Default"? Not nice, but it works (somehow...)

Comment 10

11 years ago
Comment on attachment 295375 [details]
Screenshot of Event dialog with a Google Calendar selected and the privacy popup opened.

r=christian
Attachment #295375 - Flags: ui-review?(christian.jansen) → ui-review+

Comment 11

11 years ago
Comment on attachment 295375 [details]
Screenshot of Event dialog with a Google Calendar selected and the privacy popup opened.

r=christian

Comment 12

11 years ago
Comment on attachment 295375 [details]
Screenshot of Event dialog with a Google Calendar selected and the privacy popup opened.

r=christian
Comment on attachment 295374 [details] [diff] [review]
Initial set of capabilities - v1

I think the outcome of this bug is to use calICalendar::getProperty to check a calendar's capabilities, which is quite flexible.

1) You need to document the added properties at calICalendar::getProperty. namely
   - capabilities.URL.supported
   - capabilities.priority.supported
   - capabilities.privacy.values
r=dbo with that done

2) I am fine with the gdata part (though haven't tested that); r=dbo

3) Requesting additional review from mickey about the event-dialog changes; it looks good to me (and seems to work fine).
Attachment #295374 - Flags: review?(michael.buettner)
Attachment #295374 - Flags: review?(daniel.boelzle)
Attachment #295374 - Flags: review+
Comment on attachment 295374 [details] [diff] [review]
Initial set of capabilities - v1

r=mickey.
Attachment #295374 - Flags: review?(michael.buettner) → review+
I added the following text to the IDL file.


* The following calendar capabilities can be used to inform the UI or backend
* that certain features are not supported. If not otherwise mentioned, not
* specifying these capabilities assumes a default value of true
*   capabilities.URL.supported       Supports a Document Link
*   capabilities.privacy.supported   Supports a privacy state
*   capabilities.priority.supported  Supports the priority field
*
* The following capabilities are used to restrict the values for specific
* fields. An array should be specified with the values, the default
* values are specified here. Extensions using this need to take care of
* adding any UI elements needed in an overlay. To make sure the correct
* elements are shown, those elements should additionally specify an attribute
* "provider", with the type of the provider.
*
*   capabilities.privacy.values = ["PUBLIC", "CONFIDENTIAL", "PRIVATE"];

For the naming of the default value I chose "Google Default", and removed the statusbar elements.

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
No longer depends on: 297721
Resolution: --- → FIXED
Whiteboard: [gdata-cvs]
Target Milestone: 1.0 → 0.8
Sorry, but I forgot to mention that we shouldn't spread the term "URL" further. Due to <http://tools.ietf.org/rfcmarkup?doc=draft-ietf-calsify-rfc2445bis-07#section-3.8.4.6>, the URL property refers to a "more dynamic rendition" of the calendar object which is different from how the event dialog uses that property, i.e. linking to an attachment. So IMO we should rename it as e.g. "capabilities.attachments.supported".
Additional patch to change to "attachments".
Attachment #296525 - Flags: review?(daniel.boelzle)
Comment on attachment 296525 [details] [diff] [review]
[checked in] Change URL to attachments

r=dbo
Attachment #296525 - Flags: review?(daniel.boelzle) → review+
Comment on attachment 296525 [details] [diff] [review]
[checked in] Change URL to attachments

Additional patch checked in on both branches.
Attachment #296525 - Attachment description: Change URL to attachments → [checked in] Change URL to attachments
(Assignee)

Updated

11 years ago
Whiteboard: [gdata-cvs] → [gdata-0.4]
You need to log in before you can comment on or make changes to this bug.