Feat/map processing pvc#135
Conversation
…map datastructures from files)
| /// * FrameworkReturnCode::_SUCCESS if output map is available | ||
| /// * FrameworkReturnCode::_NOT_FOUND if data is not available | ||
| /// * else FrameworkReturnCode::_ERROR_ | ||
| [[deprecated("the output map is directly saved by the map processing service on the persistent volume and can be retrieved via its UUID")]] |
There was a problem hiding this comment.
What about removing completely those methods marked as deprecated, since apparently getProcessedMap now returns NOT_IMPLEMENTED , so it's not deprecated, it's just no longer here. Deprecated would mean, it still works but it is not recommended to use it as it will eventually be removed. Here, it's actually already removed.
| protected: | ||
|
|
||
| // Injected components | ||
| SRef<SolAR::api::storage::IMapManager> m_mapManager; // Map Manager used to load and save map datastructure |
There was a problem hiding this comment.
I'm not sure about declaring member variables to be used by the child classes.
What about:
- passing all required parameters to the load/save methods?
- these could also be moved elsewhere: IMapProcessingPipeline could be separated to the way the maps are stored. Here we force to use a file, but map could be stored/loaded from DB, network, .... So maybe keep this as a pre interface, and make implementation use some utils component/helpers to managed how Maps are handled via UUIDs.
| virtual FrameworkReturnCode setMapToProcess(const SRef<SolAR::datastructure::Map> map) = 0; | ||
|
|
||
| /// @brief Set map to process | ||
| /// @param[in] mapUUID input map to be processed (will be retrieved from the persistent volume) |
There was a problem hiding this comment.
This notion of persistent volume may be to specific for this interaface. Let the implementations choose how they manage the Maps.
| return FrameworkReturnCode::_ERROR_; | ||
| } | ||
|
|
||
| // Reset the map history |
There was a problem hiding this comment.
As commented in Sample-MapManager PR, maybe not the role of saveToFile to manager history ?
If save/load didn't deal with map history, and if MapManager had an API to change its directory dynamically instead of relying on property lookup, we wouldn't really need those methods, as it would just be calls to
m_mapManager->saveToFile();
m_mapManager->loadFromFile();...
2 participants
No description provided.