On Sun, 2014-08-31 at 15:45 -0700, Todd Wilson wrote:
On Fri, Jul 11, 2014 at 12:02 PM, Todd Wilson
<twilson(a)csufresno.edu>
wrote:
Thanks for this assessment. I appreciate the effort
you've put
into getting me to this point. At least I can continue to use
SE to back-up my Zimbra calendar, which is what I've been
doing. And I'll see if I can run the database tests you asked
me for previously.
I reported all of that too Google engineers and was
told that they are
working on it. It might not be fixed next week, but it
shouldn't take
months or years either (as in the past). I'll keep an
eye on this.
I checked again and the biggest issue on the server, not being able to
update individual events in a meeting series, is now fixed. The
remaining issues are lack of support for removing individual events from
such a series (one can only remove the entire series, removing some has
no effect) and all-day recurrence exceptions (RECURRENCE-ID gets mangled
- this case should be rare in practice).
The removal issue does not affect "refresh-from-local" syncs, only
two-way syncs where individual items were removed. So again, this should
not be an issue in practice.
Overall it seems that Google CaldDAV now can also be used in two-way
mode.
Thanks! If they get the problems fixed that will be great.
Also, I'd be very interested in knowing what they think of
allowing users to subscribe to password-protected calendars --
it seems like it would be easy to do, as easy as respecting
username and password fields in the calendar URL and using
already-existing features of their HTTP(S) client library. For
example, do they have a good reason to refuse to implement
this? Is it planned but low priority? Or is it something we
might also expect relatively soon?
Please ping me again end of August.
I forgot to check this earlier and ask Google. The calendar team is
active in StackOverflow, so I have asked there:
http://stackoverflow.com/questions/25669144/google-caldav-access-to-share...
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.