Open Bug 394443 Opened 17 years ago Updated 2 years ago

composite calendar flaws

Categories

(Calendar :: Internal Components, defect)

defect

Tracking

(Not tracked)

People

(Reporter: dbo, Unassigned)

Details

- It cannot reliably fulfill calICalendar::getItem since an item's UID need not be globally unique, but is scoped to the single calendar (collection wrt CalDAV <http://tools.ietf.org/rfcmarkup?doc=4791#section-4.1>). I consider that rule rather inpracticable, because once an invitation is sent out to another calendar, it's hard to maintain resp. may put a burden on mapping external/internal UIDs, but it's specified.

- It multiplexes getItems calls to all contained calendars, sending a final onOperationComplete if all operations have completed. If only a single contained calendar fails to send it, no onOperationComplete will be fired at all; I consider this being rather fragile. May this relate in any way to bug 393387?

- The refresh/onLoad mimic doesn't fit (and doesn't scale); the views could by far better refresh calendars.

- calICompositeCalendar works on URIs, thus you cannot have multiple calendars of the same URI in it. The composite code should use calICalendar::id managing its collection; changed interface proposal:
    removeCalendar(calICalendar);
    hasCalendar(calICalendar) // instead of getCalendar
Daniel, is this something in our backend we want to tackle for the 0.8 release?
Flags: wanted-calendar0.8?
It would be good to have this for 0.8
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.