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

[WIP] feat: file conversion provider #49922

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

elzody
Copy link
Contributor

@elzody elzody commented Dec 18, 2024

Summary

This PR will introduce a file conversion API endpoint, which can be called to convert a file from one type to another. Apps can register their own conversion providers (which implement IConversionProvider), and the providers can define which MIME types they support for conversion via ConversionMimeTuples.

TODO

  • OpenAPI specs
  • Flesh out some more details around the IConversionProvider interface
    • What type should it really return? Stream, resource, File, file path?

Checklist

@elzody elzody added enhancement 2. developing Work in progress feature: files feature: workflows php Pull requests that update Php code labels Dec 18, 2024
@elzody elzody added this to the Nextcloud 31 milestone Dec 18, 2024
@elzody elzody self-assigned this Dec 18, 2024
*
* @since 31.0.0
*/
public function convert(File $file, string $targetMimetype): File;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still unsure if we rather should return either a stream or just a path to a temporary file here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we probably want this to work well with the workflow engine, maybe it would make more sense to return a file path. Maybe, if a target destination is passed to the API endpoint, we could convert the file with the appropriate conversion provider, then store the file there and return its location/metadata in the response. Or, if no destination is provided, we could just use a temporary location?

For the interfaces though, maybe it would rather make sense to leave them as they are, so if the providers are called another way (say from the same app which implements it) the developer could just use it however they like. But not sure how you want to go about it.

*/
public function __construct(
private string $from,
private string $to,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something i haven't thought about but we could also make the target mime types an array here, but no strong opinion here from my side.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, do you mean that, in the scenario where the provider can convert the same MIME type to multiple other MIME types, instead of registering multiple ConversionMimeTuples for the same original MIME type with different output MIME types, it would just be one and could have an array of output MIME types it can convert it to?

Signed-off-by: Elizabeth Danzberger <[email protected]>
@elzody elzody force-pushed the feat/file-conversion-provider branch from af6ca75 to 7e8ed84 Compare December 20, 2024 22:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2. developing Work in progress enhancement feature: files feature: workflows php Pull requests that update Php code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants