Open
Bug 394443
Opened 17 years ago
Updated 2 years ago
composite calendar flaws
Categories
(Calendar :: Internal Components, defect)
Calendar
Internal Components
Tracking
(Not tracked)
NEW
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
Comment 1•17 years ago
|
||
Daniel, is this something in our backend we want to tackle for the 0.8 release?
Flags: wanted-calendar0.8?
Comment 2•17 years ago
|
||
It would be good to have this for 0.8
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Comment 3•16 years ago
|
||
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•