You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the original proposal, there are proposed three main components - Storages, Providers ad Controllers (bac6372).
I would like to hide this logic and put it one step further. The only thing the resources module would provide are ready to serve (and configurable) classes which instances offer API. This will prevent of doing Storages-Providers-Controllers communication every time, moreover it will encapsulate all the logic besides it.
In the source code it will look like (just a quick shot):
SomeClassHandlingTarballs would hide how the tarball is received, how work_dir is organized, how it caches tarballs or when/how are tarballs removed etc.
The text was updated successfully, but these errors were encountered:
Agree, only controllers would be provided as they offer the complete solution for resource handling. Storages and Resources are building blocks only supporting controller's functionality.
It does not make sense to have a storage running on one node and provider on other. The decomposition is here to provide reusable block, e.g. for caching.
In the original proposal, there are proposed three main components - Storages, Providers ad Controllers (bac6372).
I would like to hide this logic and put it one step further. The only thing the resources module would provide are ready to serve (and configurable) classes which instances offer API. This will prevent of doing Storages-Providers-Controllers communication every time, moreover it will encapsulate all the logic besides it.
In the source code it will look like (just a quick shot):
SomeClassHandlingTarballs
would hide how the tarball is received, howwork_dir
is organized, how it caches tarballs or when/how are tarballs removed etc.The text was updated successfully, but these errors were encountered: