That is a lot more work than when your colleague tells you, please change the hostname or remove /test from the path. It is changes like that from refactoring or development process that are different each time. If this was to be supported, the cache should be cleared of course.
this was really just an idea to make icsdroid even more attractive and because I didn’t know about etag support in icsdroid. I just checked and most of my feeds do, I just wrote to teamup.com support to ask if they could add it
And it came to mind for the other use-case I described (respecting the cache-timeout header if the server sends one) because per-collection sync would be a prerequisite.
Honestly, icsdroid works great for me, this is just to foster it’s position as the best tool available 8-)
(a prerequisite would be to have per-collection sync intervals.)
Then you could respect http header meta-information, e.g. when it tells you how long this resource may be cached or when its expiring (and then trigger a new sync).
This could help save bandwith and computing time on the long run if servers send correct headers.
Yes, but the button is is appealing too. On https://icsdroid.bitfire.at/ the “Get it on Google Play” looks a bit lonely on the large gray square. On https://icsdroid.bitfire.at/download/ it is so far “below the fold” and in a different layout that I didn’t notice it. Hence that these buttons, with the same styling, give users of all stores in one quick look all they need to know on what stores this app is available. Understandable that you want a disclaimer since it is a build you don’t do yourself. However, it is a build that is monitored very strictly and openly, so I think you can list it proudly.
@max Synchronizing calendars in both directions is a very complex task, and it takes more than just downloading and uploading a single .ics file per calendar. If you have a look at CalDAV and which problems it solves, you will see what the problems are. You will also need a hierarchy: just think about the case that one .ics file contains a certain event, and the other doesn’t. So, does it mean that it has been deleted by the user and should be deleted from the one .ics file, too, or has it just been added and should be added to the other .ics file?
That make sense. So please consider this a feature request, as opposed to a bug report.
Using ASCII is fine for now, there are few french-speaking websites using IDN.
But there probably many arab/chineese/russian-speaking websites that do, so it may be more annoying for those users.
N.B. I’ve sent a flattr micro-donation as a gesture of support
Indeed, the concerned admin took care of it and was quite grateful for the help I could provide thanks to your replies!
The beginning of the generated .ics-files now looks like this:
As far as I understood the problem, this should keep it fixed even after the next clock change.
Thanks again for your help!
This is a conceptual idea: after a sync, show a message bar indicator (for calendars selected beforehand), that X events updates, Y added, Z deleted. Then you can tap on this notification and get a more complete summary where it says “EVENT TITLE updated, EVENT TITLE deleted/added”, etc.