- 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?
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-
You need to log in before you can comment on or make changes to this bug.