Caching of map display & track infos - opinions ?
fingeradmin created the topic: Caching of map display & track infos - opinions ?
- fingeradmin
- Topic Author
- Offline
- Posts: 249
- Thank you received: 44
Hi there,
i am thinking about an extended caching feature that could make the pages with gpx tracks load faster. I'm not yet sure how to implement it, so if you have any comments / suggestions, feel free to reply!
Situation:
Currently, the plugin generates a piece of html code with embedded Javascript for the map and replaces the {gpxtrackmap}...{/gpxtrackmap} part in the article with this html code. To obtain and calculate track infos (min/max speed etc.), the plugin also reads and parses the entire gpx track file, and it currently does this for every single page display. Especially when you have large tracks with many trackpoints this can cost quite some time, slowing down page display.
Now my idea is: Once the html code is generated, the plugin could save that to a file. On next request of the map, it would find and use this file instead of re-reading and re-parsing the gpx track file every time.
While the idea sounds good, it does have some drawbacks that i would like to discuss here:
- the html code would be generated with the settings / presets / layout templates as they are set at that time.
- this means that if you change settings or layouts afterwards, you would have to disable the Cache option, and go to (all?) the pages on your site with track maps on them ("re-visit" them) to force the plugin to rebuild the html code fragments with the new settings.
- if you make changes to the track file(s) themselves and upload new versions: same procedure as above: force a rebuild by (temporarily) disabling the cache.
- one more (important) aspect here is security: the plugin would have to store the html cache files alongside with the gpx track files - which is usually in a "public" folder like the default /images/gpxtracks. Since it would just load and include the files, an evil attacker could manipulate the cache files (this of course depends on how your installation is set up).
One alternative to this would be: store ONLY the track infos in a cache file, to save re-parsing of the gpx files on every page visit, but leave the dynamic html generation as it is. This would mean direct response to changes in parameters/templates without having to force a "cache rebuild", but it would not save as much time for page display as the first option. Otoh, in terms of security i like this approach much better...
Any thoughts, comments, preferences from your side?
thanks in advance & cheers, Frank
Please Log in to join the conversation.