Is there a way to change sync frequency? about ical HOT 12 CLOSED

I removed the default value for X-PUBLISHED-TTL. This library is for creating .ics as well as for creating endpoints providing icalendar data for sync. I think the value isn’t needed as default for the most people and it can be setted very easily. The absent of this value is at least not hindering the clients from updating as often as they want.

The unpublished version 0.12 contains breaking changes anyways like the PHP version constraint.

from ical.

I would guess it is respecting X-PUBLISHED-TTL:P1W 1 Week being 168 hours. You can change that with $vCalendar->setPublishedTTL('P1H'); (changes it to one hour).

from ical.

Hey @naneri,

I am not aware of any restriction that can be set in .ics files to prevent the client to update. Maybe you can show more of your problem? How does your generated .ics file look like? How does the code look like that generates the file?

from ical.

    public function generateIcal($user_id)
    {
        $vCalendar = new Calendar(config('app.url'));

        $plans = MealPlan::where('user_id', $user_id)->get();

        foreach($plans as $plan){
            $vEvent = new Event();

            $vEvent
                ->setDtStart(new \DateTime($plan->date))
                ->setDtEnd(new \DateTime($plan->date))
                ->setNoTime(true)
                ->setSummary($plan->type);

            $vCalendar->addComponent($vEvent);
        }

        return response($vCalendar->render())
            ->withHeaders([
                'Content-Type'          => 'text/calendar; charset=utf-8',
                'Content-Disposition'   => 'attachment; filename="cal.ics"'
            ]);
    }

Here is the code.

from ical.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:http://anya.dev
X-PUBLISHED-TTL:P1W
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20161229
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20161229
SUMMARY:breakfast
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20161229
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20161229
SUMMARY:breakfast
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20161230
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20161230
SUMMARY:breakfast
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20161230
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20161230
SUMMARY:breakfast
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20170104
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20170104
SUMMARY:lunch
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20170104
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20170104
SUMMARY:snacks
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20170105
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20170105
SUMMARY:breakfast
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20170109
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20170109
SUMMARY:snacks
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
BEGIN:VEVENT
UID:58748a622bdc4
DTSTART;VALUE=DATE:20170107
SEQUENCE:0
TRANSP:OPAQUE
DTEND;VALUE=DATE:20170107
SUMMARY:breakfast
CLASS:PUBLIC
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
DTSTAMP:20170110T131650Z
END:VEVENT
END:VCALENDAR

from ical.

In the generated .ics file I cannot see anything that will prevent the consumer/client to update the information from that file. Normally caching would be the concern of a different layer. Normally the iCal files are transferred using HTTP. Any rule for caching etc. could be made there.

One thing that looks wrong in the generated is that the events have the same UID instead having their own UID that must differ from all others. (I will have a look into that later but this might not be your actual problem here.)

Which version of Outlook are you using? Did you already search for the message and how to avoid it?

from ical.

As a conclusion: to me this problem looks like a problem fro the client rather than from the generated .ics file. You could also try another client instead of Outlook to verify that.

from ical.

@markuspoerschke it seems that the problem is with Microsoft Outlook, it thinks that all .ics set update rate to 168 hours, by default, and for instance on Mac you can sync the events manually or with much higher frequence (like every five minutes at least).

from ical.

@naneri Can I close this issue then?

from ical.

I was really not ready this issue carefully enough.

@jrjohnson Do you have expirience with this property? Do you think the default value of 1 week makes sense? Maybe it is better to drop the default and make it optional?

from ical.

I've personally always set it at one hour - but that makes the most sense for our use case. I would see removing the default as a breaking change for anyone relying on it - but other than that I only have our own usage to compare it to.

from ical.

RFC 7986 introduced a REFRESH-INTERVAL property:

https://www.rfc-editor.org/rfc/rfc7986#section-5.7

from ical.