Partial conversion of files when calling trac.mimeview.api.Mimeview.convert_content

[olemis+trac@…]

In the aforementioned function there is a branch that is used to guess the content type of the input file. In order to do that max_preview_size bytes are read from the beginning of the file, and then the file is not used anymore. This means that only that first block is converted rather than the whole file.

The exact location of the code I am talking about is here​

[Remy Blank]

Well, yes, that's what max_preview_size is intended for. What were you expecting? Can you describe the situation where this is not desired?

[Christian Boos]

Maybe in some situations, previewing a truncated document is not a good idea (at the very lest, the document will appear to be complete while it's actually truncated).

It would be preferable to not preview the content if its size is above the given limit. Related to #3332, as it would be nice to be able to get the size of the content without requiring to read it first.

[olemis+trac@…]

Replying to cboos:

Maybe in some situations, previewing a truncated document is not a good idea (at the very lest, the document will appear to be complete while it's actually truncated).

That's part of the whole picture. BTW there are some other situations that could be considered e.g. the last bytes are needed to render the file. In my particular case, I am writing a plugin and I'd like to convert the whole file from original MIME type to target MIME type. If the file is truncated I cannot rely upon Trac MIME API to do that (therefore needing to reinvent the wheel due to a minor implementation detail).

It would be preferable to not preview the content if its size is above the given limit.

Therefore IMHO it would be better to perform such decisions outside the API itself (e.g. the plugin using the API for a particular purpose) or otherwise inside of it, but having the possibility to specify what is needed explicitly (I think I'd be +1 for the former ).

Related to #3332, as it would be nice to be able to get the size of the content without requiring to read it first.

Probably yes. That would be very useful to decide what to do before actually doing it ;o)

PS: Real-time preview is awesome. Keep up the good work !

:o)

[Carsten Klein <carsten.klein@…>]

perhaps splitting the mimetype api into a backend and frontend would do the job? with the backend being able to process arbitrary file sizes, and the frontend imposing a size limit to it?

afaik the original poster wants to implement some kind of conversion utility for mimetypes, in order to be able to transform arbitrary input types into arbitrary output types…

[olemis+trac@…]

Replying to Carsten Klein <carsten.klein@…>:

perhaps splitting the mimetype api into a backend and frontend would do the job? with the backend being able to process arbitrary file sizes, and the frontend imposing a size limit to it?

afaik the original poster wants to implement some kind of conversion utility for mimetypes, in order to be able to transform arbitrary input types into arbitrary output types…

Exactly ! … but with efficiency in mind, so that if all contents are not needed then only some bytes are read