Open IgelCampus opened 4 years ago
The API of a fritzbox can differ from model to model and can also change after a software update. That leads to the situation, that for a configuration-cache validation the configuration must be read – so the configuration has to be read anyway. However, it may be possible to cache the scpd-files. May be I can go into this for one of the next versions.
You could also auto-refresh after either hard-coded 24h or when another optional parameter value is exceeded. In addition, even when the firmware gets an update i am not aware that AVM ever removed a feature so in worst-case you might have one feature not available until the cache timeout kicks in. And even this is only theoretical as the caller must explicitly change his code to use the new feature and would probably also disable or simply clear the cache while working on the code.
If the cache "key" is a combination of device name and version and the auth data, then it's always up-to-date, isn't it?
Yes, it would be up to date. But to get the device name and version to build the key one have to read this information first from the box – unfortunately these are part the data to cache. Also it is recommended by AVM to inspect the API first before doing any action. However, a kind of cache could be optional and at own risk. But the problem of "own risk" is, that people often don't realise this and blame others. In case of a cache feature I'm sure this will happen sooner or later.
Okay sounds that's a bad idea to add caching.
Found a way for proper caching – at least I think so. Will merge this to the next release.
I am monitoring a remote fritzbox with several Fritz!DECT200 and 301 devices. The monitoring software (munin) runs every 5 minutes and starts ~12 scripts. Each script uses fritzconnection to connect to the remote box and extracts a single value. Because fritzconnection starts from scratch on every call it has to download all the xml files before the actual call can be executed. In my setup getting the xml descriptions takes ~25 seconds and then another second for the call to request the wanted information.
I therefore propose the introduction of a file-based cache for the given address, maybe by adding another parameter cacheDir which must point to an existing directory where a sub-directory for each ip-address is created which contains the xml files as downloaded on the first run.