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
At the moment, AF is designed for "interactive browsing". This means that the client first queries the provider for a list of assets (using the datablock ˋasset_list_queryˋ) and then for a list of implementations for one specific asset (using the datablock ˋimplementation_list_queryˋ on that asset).
This presents an issue if the provider wants to also allow batch downloading of their assets as it requires the client to contact the provider again and again to get the implementations for every asset. Moreover, if the provider has a more elaborate setup where the implementation list query varies between assets (for example because different asset types have different quality vectors, such as resolution, poly count, bit depth...) then the client needs to anticipate every possible query configuration - which it can't, unless it has existing knowledge over the provider and what kind of query parameters it might offer.
Option 1: New batch downloading endpoint
To make batch downloading easier in those cases where it is desired, a new datablock and endpoint could be created.
The datablock ˋimplementation_batch_list_queryˋ would be a variable query to a new ˋimplementation_batch_listˋ endpoint.
This endpoint would, based on the parameters of the query, return a finished list of implementations that the client can then download one after the other.
Unlike during normal operation, the provider would not offer different implementations but rather just ask the client which kind of implementation (which data format etc.) it wants. An open question is how the IDs of assets (which the client may want to use for organization local storage) would be communicated in this structure. They could be simply added to the implementation JSON in some way, but this would create a small and potentially confusing different between the two endpoints. Maybe there is a better way.
Option 2: Datablocks for hinting available parameters
Another approach that perhaps requires less new structures is to use a "batch hint" that the provider adds to the output of the ˋasset_listˋ output. It would show the client which parameters it should expect to find on every implementation list query, thus allowing the client to automatically run through the entire asset list with confidence (i.e. without the possibility that one of the implementation lists requires additional parameters that it wasn't prepared for).
At this point, I wouldn't call either option "ideal" to be honest.
The text was updated successfully, but these errors were encountered:
At the moment, AF is designed for "interactive browsing". This means that the client first queries the provider for a list of assets (using the datablock ˋasset_list_queryˋ) and then for a list of implementations for one specific asset (using the datablock ˋimplementation_list_queryˋ on that asset).
This presents an issue if the provider wants to also allow batch downloading of their assets as it requires the client to contact the provider again and again to get the implementations for every asset. Moreover, if the provider has a more elaborate setup where the implementation list query varies between assets (for example because different asset types have different quality vectors, such as resolution, poly count, bit depth...) then the client needs to anticipate every possible query configuration - which it can't, unless it has existing knowledge over the provider and what kind of query parameters it might offer.
Option 1: New batch downloading endpoint
To make batch downloading easier in those cases where it is desired, a new datablock and endpoint could be created.
The datablock ˋimplementation_batch_list_queryˋ would be a variable query to a new ˋimplementation_batch_listˋ endpoint.
This endpoint would, based on the parameters of the query, return a finished list of implementations that the client can then download one after the other.
Unlike during normal operation, the provider would not offer different implementations but rather just ask the client which kind of implementation (which data format etc.) it wants. An open question is how the IDs of assets (which the client may want to use for organization local storage) would be communicated in this structure. They could be simply added to the implementation JSON in some way, but this would create a small and potentially confusing different between the two endpoints. Maybe there is a better way.
Option 2: Datablocks for hinting available parameters
Another approach that perhaps requires less new structures is to use a "batch hint" that the provider adds to the output of the ˋasset_listˋ output. It would show the client which parameters it should expect to find on every implementation list query, thus allowing the client to automatically run through the entire asset list with confidence (i.e. without the possibility that one of the implementation lists requires additional parameters that it wasn't prepared for).
At this point, I wouldn't call either option "ideal" to be honest.
The text was updated successfully, but these errors were encountered: