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
>
>