-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
base: master
Are you sure you want to change the base?
Conversation
* | ||
* @since 31.0.0 | ||
*/ | ||
public function convert(File $file, string $targetMimetype): File; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ConversionMimeTuple
s 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]>
af6ca75
to
7e8ed84
Compare
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 viaConversionMimeTuple
s.TODO
IConversionProvider
interfaceChecklist