Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling Batch downloads #50

Open
struffel opened this issue Oct 13, 2024 · 0 comments
Open

Handling Batch downloads #50

struffel opened this issue Oct 13, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@struffel
Copy link
Contributor

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.

@struffel struffel added the enhancement New feature or request label Oct 13, 2024
@struffel struffel added this to the v0.5 milestone Oct 13, 2024
@struffel struffel self-assigned this Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant