Re: Event dialog > Attachments has no effect on Google calendar?
STF <[email protected]> Thu, 19 May 2016 16:06:58 +0200
| Newsgroups | gmane.comp.mozilla.devel.calendar |
|---|---|
| Message-ID | <[email protected]> |
On 2016.05.17 10:51, Philipp Kewisch wrote: > On 5/17/16 10:40 AM, STF wrote: >> On 2016.05.16 23:20, Stefan Sitter wrote: >>> On 16.05.2016 20:29, STF wrote: >>> Are you using the build-in CalDAV provider or the Provider for Google >>> Calendar extension to access your calendar? >> >> CalDAV provider. >> >> (I always prefer something general having a broad and widely accepted >> standard than specific implementation which has its own "standard" -- >> the day when the guys who know this specific implementation are gone, >> the product will virtually be dead) > > It may well be that Google does not store the properties when using the > caldav access. I'm very surprise to hear this. I always thought if a program is unable to process a property, it would just leave it alone instead of destroying it. So you're basically speculating that the string presenting the event is not stored in its entirety, right? > You can check it by enabling the debug prefs and noting > the difference between what is sent and what is received. What to do exactly? I mean, are talking about about "about:config"? And what is the preference name? >>> Does Google support adding attachments links to an event using the >>> Google Calendar web interface? >> >> I would say "sort of yes". In Google Calendar web interface, the >> attachment function lets us attach files. So I suppose I could create a >> shortcut file and attach it. > I don't think these attachments are exposed via CalDAV. Weird. I always thought the CalDAV is the transport which doesn't care of the content. I mean, it's much like HTTP: we can invent any tag we like inside an HTML document, like <this_is_my_tag>xxxxxxyyyyy, whatever</this_is_my_tag> HTTP doesn't care if the tags are supported by HTML standard or not. Its job is transport. It does not care of the content which is a LONG string. > Philipp > >