Calendar module fetchInterval

Anhalter42

Is the fetchInterval property of the standard calendar module really restricted to Possible values: 1000 - 86400000 like specified in the documentation? If so, two questions:

Where do I find the code restricting it? I couldn’t find it while reading through the code.
Why is it restricted? Is there any reason to limit the update interval at all? (especially, why giving an upper bound? The lower bound is somewhat reasonable…)

Thx.

Anhalter42

I’m still interested in this. Does anyone know?

As far as I can tell, no explicit restriction to the fetchInterval is implemented in this module. Assuming my observation is correct, this would imply that the actual max. value for fetchInterval is 2147483647 (~ 24.8 days) according to stackoverflow Why does setTimeout() “break” for large millisecond delay values?.

strawberry 3.141

@Anhalter42 Maybe there was one someday and the code was changed over time and the readme wasn’t adjusted accordingly or it is as a direction for users that aren’t familiar with those numbers so they don’t put something weird in it. Either way I can’t see a reason to sync a calendar less then a day?

Anhalter42

@strawberry-3.141 Thx. Mh usually you are correct, but for example holidays as given in the example config of this module don’t change ever. There is no point in updating this hourly (unnecessary traffic for self and server). Instead, for something like this it would be sufficient to update yearly or even “never” (it updates at start and I guess you usually restart the mirror once a year).

cohron

@Anhalter42 so should the fetchInterval be moved to the calendar array since some calendars only need to be updated once (holidays) and others more often. just a thought have a defaultFetchInterval at the module level and fetchInterval for calendar level?

Anhalter42

@cohron Well… yes. Are you interested in implementing this? If you don’t rename the existing option fetchInterval (instead call the new options overwriteFetchInterval or something), it should be compatible with existing config files and therefore likely to be accepted.

bhepler

@strawberry-3.141 - I can. If you have a personal calendar (Google, Outlook, Apple, etc.) that you update frequently, you probably want to refresh it hourly or so. My wife and I use our Google calendars extensively to keep each other up to date on everything from doctor’s appointments, working late, running errands at the store/cleaners/bank. Basically anything that might throw our expected schedules off. It keeps us from starting unnecessary search parties (my wife has a serious health condition - if she doesn’t show up on time, there is a non-trivial chance she’s unconscious somewhere)

When I get the home mirror set up, we’ll probably shift to a shared calendar that we can both add events.

strawberry 3.141

@bhepler I’m the same oppinion as you are, probably didn’t explain it well. I can’t see a point why you would care to fetch less frequent than a day.

bhepler

@strawberry-3.141 Aha! Yeah, I misunderstood. “less than a day” = “less frequently than at least once per day”, as opposed to my interpretation. My interpretation was “a frequency interval of less than one day”.

Interesting question: Does the calculation that writes out the “xx days” string only occur on the fetch? For example, if I have an event in four days and I don’t perform a fetch for a week, will it correctly change the text to read “day after tomorrow” at the appropriate time?

If I were only showing holidays on my calendar then such a thing might make sense. How often do holidays change, right?

cohron

@Anhalter42 Definately, and excellent point about not changing the existing option name. I’m hoping to implement a (swimming) pool module in the next couple of months. I haven’t coded (VB) in over a decade so i am reading up about Github (great concept btw). Not sure if i need to branch or pull request or what just yet. I think i can handle learning JS and use the existing modules to reference. This will be a great exercise for me before i jump into full coding.