We need the ability to differentiate from providers that do their own invitation handling (i.e. GDATA and WCAP) and those that use out-of-band mechanisms like email. Philipp had an excellent idea about the way to do this using a property on the provider interface. Here is his comment (from review on bug 379198): > > >+ // XXX Until we rethink attendee support and until such support > >+ // is worked into the event dialog (which has been done in the prototype > >+ // dialog to a degree) then we are going to simply hack in some attendee > >+ // support so that we can round-trip iTIP invitations. > >+ // Since there is no way to determine the type of transport an > >+ // attendee requires, we default to email > To allow providers to override this, what do you say we add a provider property > like so: > > var transportType = item.calendar.getProperty("itip.transportType") || > "email"; > var emlSvc = > Components.classes["@mozilla.org/calendar/itip-transport;1?type=" + > transportType] > > .createInstance(Components.interfaces.calIItipTransport); > I think this could dovetail nicely with the work needed to create an invitation manager component that would watch all calendars and keep track of the invitations on those calendars.
+1 my draft caldav-sched calIItipTransport code has had to resort to '(if item.calendar.type == "caldav")' hacks thus far. I think this is exactly what's needed.
Either soft property or real API, it's wanted for 0.9.
Version: Trunk → unspecified
This bug might be fixed in bug 428392. Its an open question if the changes made are enough to allow custom transport types. Unfortunately, I have found out there is no API to fully handle invitations in gdata. I might have to revert to doing email based scheduling also for gdata.
Fixed in bug 428392.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 428392
You need to log in before you can comment on or make changes to this bug.