SyncDelay

[Lonestarjeepin]

SyncDelay processes each source Calendar individually instead of grouping them together by Target Calendar before processing. By handling each calendar individually, I was able to define a SyncDelay on a per-calendar basis. The default is whatever the script trigger (howFrequent) is set to, but the SyncDelay can be set to skip syncing on a given run if the SyncDelay hasn't "expired". For example: if howFrequent is 15, but SyncDelay on a given calendar is 60, then that calendar will only sync once every 4th iteration of the script (aka once per hour). However, another calendar in the same script could still sync every 15 minutes.

For the developers: I had to modify the fromGAS entries (5 in total) to use the sourceCalendarName instead of "true" to avoid conflicts with multiple sources writing to the same target calendar (but not at the same time). However, the first time you run this new code, that change itself will cause duplication of all events that currently existed because they were from fromGAS=true. I didn't include it here, but a possible solution would be to put in a step that checks for fromGAS=true and removes all of those events.

[Lonestarjeepin]

I'm running into version-control issues so this pull actually has the code from #358 as well as #217 . I'm sure this probably isn't the right way to do it... sorry!

[derekantrican]

I'd really like to avoid adding additional properties to the calendars arrays until they're redesigned (see #311). However, if this is critically needed for some reason, feel free to say so and we can discuss it further

[Lonestarjeepin]

I wouldn't say the feature itself is critical (defining multiple sync schedules) although it was requested in #346 which gave me a use-case to implement this change. My main impetus in redesigning the script this way was to enable a lot of other feature-requests I've seen that (to me) would need to be executed at the individual source-calendar-level rather than the target-calendar-level. The Sync Delay feature is just a Trojan Horse for the real change in how the code executes. I agree that defining more and more parameters on the individual source calendars could be messy in the current configuration of the script and totally agree with your direction in #311. I was just hoping this might open some doors to accomplish other feature requests... and I got stuck on the idea so I couldn't stop until I figured it out!!!

[jonas0b1011001]

For the developers: I had to modify the fromGAS entries (5 in total) to use the sourceCalendarName instead of "true" to avoid conflicts with multiple sources writing to the same target calendar

By using fromGAS=${ScriptApp.getScriptId()} we would allow users to set up multiple independant copies (with different sync intervals) of the script working on the same target calendar.

[Lonestarjeepin]

I've used that when I have two (or more) different scripts writing to the same target calendar, but given that this would be the same script writing to the target calendar multiple times I think that would still cause conflicts. I didn't test it though. Example: SourceCalA reads from TargetA 0 events (let's assume this is the first run ever, but the same logic would apply to subsequent runs). SourceCalA contains 30 events so 30 get written to TargetA. Then SourceCalB wants to write to TargetA also (in the same script as SourceCalA). SourceCalB would then read 30 events from TargetA as being from getScriptId() and think they are events it should understand. So then those 30 would get deleted (because they aren't contained in SourceCalB) and SourceCalB would then write x new events to TargetA. So each SourceCalx would always conflict with any other SourceCaly every time the script is run and only the last one in the loop would exist in Targetx.

Keep in mind the main change I made to this version is to have each SourceCal run individually instead of collapsing them together to run against a given Target (I completely removed condenseCalendarMap). The variable "triggers/delays" was just one feature this change enabled. My hope is this change will enable other source-calendar-specific features to be deployed in the future (handling 5xx errors, only syncing specific days per source calendar, etc.). Even some of the current global variables (onlyFutureEvents, addEventsToCalendar, etc.) could be individualized per source calendar. I know Derek doesn't want to over-parametize (if that's a word) and I totally get that so I'm not trying to open Pandora's box. But if #311 can be figured out, this could be the foundation it could be built upon to enable more fine-grain control of source calendars.

FWIW, we could use sourceURL as the fromGAS. We don't need a separate parameter. It just needs to be unique for each SourceCal. I just thought the friendly name would be easier for troubleshooting when reading the logs, etc. and I think I even saw a feature request where someone was asking for that SourceCal name to be appended to the event title or something like that so it could serve multiple uses.

On Tue, Oct 10, 2023 at 4:26 AM jonas0b1011001 @.***> wrote:

For the developers: I had to modify the fromGAS entries (5 in total) to use the sourceCalendarName instead of "true" to avoid conflicts with multiple sources writing to the same target calendar

By using fromGAS=${ScriptApp.getScriptId()} we would allow users to set up multiple independant copies (with different sync intervals) of the script working on the same target calendar.

— Reply to this email directly, view it on GitHub https://github.com/derekantrican/GAS-ICS-Sync/pull/372#issuecomment-1754805761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7OH5PBKWL64NMNAMT36H3X6UIDBAVCNFSM6AAAAAA5L2UFW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJUHAYDKNZWGE . You are receiving this because you authored the thread.Message ID: @.***>

[jonas0b1011001]

I totally get that. My suggestion was more like a possible easy to do workaround for different sync intervals..until we get #311 and possibly a quite substantial code overhaul done.

[Lonestarjeepin]

Gotcha. I wasn't planning on this, but if I take a stab at #311, what do you see as the features that need to be captured to enable that? I'm seeing something like a list of source calendars that the user can choose from (or option to add new/delete). Then once they select a source calendar from the list, it would bring up a details page for that source calendar where all of the relevant parameters could be set either through checkboxes, dropdowns, input fields, etc. depending on the parameter. Are you seeing anything different or something I've missed?

KW

On Wed, Oct 11, 2023 at 10:15 AM jonas0b1011001 @.***> wrote:

I totally get that. My suggestion was more like a possible easy to do workaround for different sync intervals..until we get #311 https://github.com/derekantrican/GAS-ICS-Sync/discussions/311 and possibly a quite substantial code overhaul done.

— Reply to this email directly, view it on GitHub https://github.com/derekantrican/GAS-ICS-Sync/pull/372#issuecomment-1757925892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7OH5MYJD3J3KCUSFQDHDDX62ZZTANCNFSM6AAAAAA5L2UFWY . You are receiving this because you authored the thread.Message ID: @.***>

[jonas0b1011001]

311 is about replacing the sourceCalendars array with a js object. Creating a html UI is not neccessarily needed for that, however i don't want to stop you from giving it a go ;P

[Lonestarjeepin]

That makes sense, but Derek made a comment in there about some efforts in the past to develop an HTML UI too. Do y'all have any of those old attempts you could share? I've never done any of this in Google Script, but I'm guessing the HTML could read/write to the JSON so people could use either one??

On Wed, Oct 11, 2023 at 11:37 AM jonas0b1011001 @.***> wrote:

311 https://github.com/derekantrican/GAS-ICS-Sync/discussions/311 is

about replacing the sourceCalendars array with a js object. Creating a html UI is not neccessarily needed for that, however i don't want to stop you from giving it a go ;P

— Reply to this email directly, view it on GitHub https://github.com/derekantrican/GAS-ICS-Sync/pull/372#issuecomment-1758080325, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7OH5IMPMR22F7ZGGFAQQLX63DK3ANCNFSM6AAAAAA5L2UFWY . You are receiving this because you authored the thread.Message ID: @.***>

[jonas0b1011001]

There is one in this repo https://github.com/derekantrican/GAS-ICS-Sync/tree/HTML-UI and i have one on mine aswell https://github.com/jonas0b1011001/GAS-ICS-Sync-CalAPIv3/tree/HTML-Webinterface