feat: file conversion provider #49922
Conversation
elzody
added
enhancement
2. developing
elzody
force-pushed
the
feat/file-conversion-provider
branch
2 times, most recently
from
7e8ed84 to
3ab63cb
Compare
elzody
force-pushed
the
feat/file-conversion-provider
branch
from
b1d9670 to
1bceac6
Compare
elzody
force-pushed
the
feat/file-conversion-provider
branch
2 times, most recently
from
2cdd54b to
e91c447
Compare
elzody
force-pushed
the
feat/file-conversion-provider
branch
3 times, most recently
from
ac0843f to
e8d3eac
Compare
elzody
changed the title
|
|
||
| // Operate in mebibytes | ||
| $fileSize = $file->getSize() / (1024 * 1024); | ||
| $threshold = $this->config->getValue('max_conversion_filesize', 100); |
There was a problem hiding this comment.
Wouldn't it make sense to also check that the threshold is a sensible value? Otherwise an admin might configure something like 100 GiB and break their instance. I'm not sure what a reasonable limit is, especially when it comes to high resolution photos or long (high resolution) videos.
There was a problem hiding this comment.
I don't see a risk of breaking the instance here. If an admin configures long timeouts then it should be fine. At some point we may rather want to have background workers that do an async conversion so we don't run into timeouts (which is the main reason for adding this), but this was discussed out of scope due to the short-term scheduling with @AndyScherzinger.
elzody
force-pushed
the
feat/file-conversion-provider
branch
from
e8d3eac to
23e4606
Compare
|
As a followup, it would be nice to add some integration tests.
|
Signed-off-by: Elizabeth Danzberger <[email protected]>
elzody
force-pushed
the
feat/file-conversion-provider
branch
from
1073cfd to
fdfeb7f
Compare
Signed-off-by: Elizabeth Danzberger <[email protected]>
AndyScherzinger
added
4. to release
|
🎉 🎉 🎉 |
| try { | ||
| $convertedFile = $this->fileConversionManager->convert($file, $targetMimeType, $destination); | ||
| } catch (\Exception $e) { | ||
| throw new OCSException($e->getMessage()); |
There was a problem hiding this comment.
We should log the exception here and rather return a generic error message as the exception message may leak server internals. Also the trace is lost.
| class ConversionMimeTuple implements JsonSerializable { | ||
| /** | ||
| * @param string $from The original MIME type of a file | ||
| * @param list<array{mime: string, name: string}> $to The desired MIME type for the file mapped to its translated name |
There was a problem hiding this comment.
@elzody @skjnldsv I just noticed when implementing a simple pandoc provider, that we may also want to have the extension as a separate property for target formats. We list it in the name, but I assume for automatically generating a file with the new extension we should also have it directly accessible so it can be used to build the target file name on the frontend side?
There was a problem hiding this comment.
Just FYI @elzody .. @skjnldsv had a quick call and noticed that the API only works with passing a destination, without we lack the ability to build the new destination filename. @skjnldsv will look into that as a follow up for the frontend.
We also had another discussion round on #49922 (comment) and decided to do a small change on the tuple drop the array to to have one tuple for each from-to mapping to be more strict on the api and not have the php array. Hope that makes sense
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 viaConversionMimeTuples.TODO
IConversionProviderinterfaceChecklist