The openeo spec wants the full description for the list of all processes. To map this, the parameter &record=full was already implemented together with a module filter (eg. &family=v) to not run into a timeout. For openeo, the r-family is the most interesting one, but is so large that it often runs into a timeout as well so that the openeo-grassgis-driver cannot use the grass gis modules.
This PR enables a cache for the GRASS GIS modules in the redis db. For requests against /grass_modules and /modules, all once requested modules are written into the db. When the endpoint to describe one module is requested (grass_modules/r.slope.aspect), the interface-description is requested again and the entry in the db will be replaced to allow an api based mechanism to reload the cache, e.g. when a module has a new parameter.
The cache is not yet used when a template description is loaded, which also takes a while, especially when the template uses many grass modules. This can be implemented later if needed.
The openeo spec wants the full description for the list of all processes. To map this, the parameter
&record=fullwas already implemented together with a module filter (eg.&family=v) to not run into a timeout. For openeo, ther-family is the most interesting one, but is so large that it often runs into a timeout as well so that the openeo-grassgis-driver cannot use the grass gis modules. This PR enables a cache for the GRASS GIS modules in the redis db. For requests against/grass_modulesand/modules, all once requested modules are written into the db. When the endpoint to describe one module is requested (grass_modules/r.slope.aspect), the interface-description is requested again and the entry in the db will be replaced to allow an api based mechanism to reload the cache, e.g. when a module has a new parameter. The cache is not yet used when a template description is loaded, which also takes a while, especially when the template uses many grass modules. This can be implemented later if needed.