More frequent reloads (without extra waiting) about giggity HOT 11 CLOSED

You mean what you get when going back to the conferences menu (with the back button), point and hold, and click "Refresh" ?

from giggity.

Exactly.

Ahh, yes, going through the conferences menu is another way instead of restarting the app. But also not very user friendly because you have to remember that the back button takes you back there - there's no menu item or visible indication how you get to the conferences menu once you're inside of a conference schedule.

from giggity.

Agreed that having to go back to the main menu isn't that fantastic. What I kinda had in mind for a while already is like #54 , allow doing it more in the background, more proactively (but only after confirming that a server supports If-Modified-Since caching) and more often than once every 24h.

from giggity.

(So let's keep that one open as the real goal?)

from giggity.

What I kinda had in mind for a while already is like #54 , allow doing it more in the background, more proactively (but only after confirming that a server supports If-Modified-Since caching) and more often than once every 24h.

The question then is how often does it check for updates? Depending on what you had in mind for that it might be good to make that configurable (or add a menu item to trigger a background reload 😄 ). I can envision that for some conferences checking every hour wouldn't be often enough...

from giggity.

b5ffc48 has an implementation for this.

Your questions above I never saw at the time I guess but are good ones. I'll address those in subsequent commits, my plan is to set a refresh time in menu.json, defaulting to 3600 but add code to the CI to penalise servers with higher timers if they don't implement If-Modified-Since/etc since that ruins caching.

from giggity.

for some conferences checking every hour wouldn't be often enough

Hmm, you really think so? 1h is what I had in mind, see above. Have you got examples where that really wasn't frequent enough?

Now I wish I had a wget loop running for CCC/FOSDEM to see how often they change during the day.. :-)

from giggity.

Some conferences are very dynamic. While the general schedule is fixed there might be additional sessions that get added ad-hoc (or there are empty slots that get filled-in as necessary), i.e. you'll better check at the end of a session what's scheduled for the next session. If the refresh happened just before the schedule got updated you'd be out-of-luck to see the current options for the next session.

It's been a long time since I wrote this issue, so I don't have any data, and I haven't been at a conference that used giggity since I wrote this issue, but IIRC the schedule at DEBCONF got updated frequently which caught me by surprise. I don't know if updating every hour would have been sufficient, but I remember that I regularly checked the schedule in giggity and on screen and several times noticed differences which caused me to restart giggity.

I guess in the end it depends on the length of the sessions how frequently it makes sense to refresh: if we have two hour slots then every hour should be sufficient from a statistics point of view, but if we have half hour or three-quarter hour sessions then it isn't frequently enough.

from giggity.

from giggity.

And I wonder whether I should go run a fetcher every 5m for all schedule files currently in the menu to measure change frequency, could be interesting. :-)

Doing that now though only at a 15m frequency. First thing I see is that 6 out of the 8 most recent schedule files in the Giggity menu are hosted by servers that do nothing useful with If-Modified-Since headers or actually serves entirely "different" content every single time you query it. Only difference being the DTSTAMP fields, or actually in one case even the UID field (which I think I'm using as permanent IDs to mark reminders).

So that's trash. These are mostly .ics files which I've always disliked anyway..

from giggity.

So, 2.0 launched with these improvements. And I'm still running this fetcher, though maybe a bit early, but it'll be fun to see the schedule update rate during events like 36c3 and FOSDEM2020. (And hopefully Giggity already dealing with them more sensibly!)

from giggity.