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

Pass hash and extension in the DistributorCopyFile payload instead of the URL #28

Open
daniil-berg opened this issue Sep 16, 2024 · 0 comments
Assignees
Labels
breaking change Changes to public functions that are not backwards compatible consistency An inconsistency that should be (re-)aligned refactoring Non-breaking changes that improve maintainability or readability web api Changes to the API exposed via HTTP endpoints

Comments

@daniil-berg
Copy link
Contributor

It seems it would be more consistent with the rest of the Distributor API, if the hash and extension of a file to be copied were passed in the already existing DistributorCopyFile payload model:

class DistributorCopyFile(BaseRequestModel):
from_base_url: str
file_size: int # in bytes

They are currently part of the URL path in the form /api/distributor/copy/<hash><ext>.

Aside from a more consistent interface, it would have the added benefit of making the payload model map nicely to the CopyingVideoFile constructor, which would further simplify both the logic and the call site of DistributorFileController.schedule_copying.

hash_, ext = request.match_info["hash"], request.match_info["file_ext"]
file_controller = DistributorFileController()
try:
file_controller.schedule_copying(
hash_,
ext,
data.from_base_url,
data.file_size,
)

Since this would be a purely internal API change, there would be no implications for external clients/LMS.

We would only have to adjust the implementation of the DistributorClient.copy method, which depends on the distributor API.

@daniil-berg daniil-berg self-assigned this Sep 16, 2024
@daniil-berg daniil-berg added breaking change Changes to public functions that are not backwards compatible consistency An inconsistency that should be (re-)aligned refactoring Non-breaking changes that improve maintainability or readability web api Changes to the API exposed via HTTP endpoints labels Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes to public functions that are not backwards compatible consistency An inconsistency that should be (re-)aligned refactoring Non-breaking changes that improve maintainability or readability web api Changes to the API exposed via HTTP endpoints
Projects
None yet
Development

No branches or pull requests

1 participant