Converters don't nest - can't handle .yml.gz #13
Comments
|
Got a patch handy? I'm just on PTO. Thanks. |
|
I will attempt to write one but haven't started yet. I figure the best thing is to re-check the mime type after a gzip decode. |
robert-ancell
added a commit
to robert-ancell/libxmlb
that referenced
this issue
Feb 24, 2019
Previously the contents were assumed to be XML, and this didn't work with GZip compressed YAML. The code isn't optimal as it writes decodes the GZipped file to a temporary file. This was done because the converter API uses a GFile instead of a GInputStream. The existing XML case doesn't use the temporary file so shouldn't have a performance hit. Fixes hughsie#13
hughsie
added a commit
that referenced
this issue
Feb 27, 2019
This is much more flexible than the existing GFile -> GInputStream converter
functions. Content types can be "nested" for instance:
application/gzip -> application/x-yaml -> application/xml
To ensure the content type is always correct when there is no filename info,
always add the XML header when building sources.
For API compatibility we also have to support the deprecated vfunc too.
Fixes #13
|
Okay, I've had a go at this too; I took what you did and rewrote it -- there is a proper context object we can extend in the future if we need to now. I've also pushed a wip/hughsie/XbBuilderSource-adapter branch in gnome-software which uses this new API -- feedback very welcome. |
hughsie
added a commit
that referenced
this issue
Feb 27, 2019
This is much more flexible than the existing GFile -> GInputStream converter
functions. Content types can be "nested" for instance:
application/gzip -> application/x-yaml -> application/xml
To ensure the content type is always correct when there is no filename info,
always add the XML header when building sources.
For API compatibility we also have to support the deprecated vfunc too.
Fixes #13
hughsie
added a commit
that referenced
this issue
Feb 27, 2019
This is much more flexible than the existing GFile -> GInputStream converter
functions. Content types can be "nested" for instance:
application/gzip -> application/x-yaml -> application/xml
To ensure the content type is always correct when there is no filename info,
always add the XML header when building sources.
For API compatibility we also have to support the deprecated vfunc too.
Fixes #13
hughsie
added a commit
that referenced
this issue
Feb 27, 2019
This is much more flexible than the existing GFile -> GInputStream converter
functions. Content types can be "nested" for instance:
application/gzip -> application/x-yaml -> application/xml
To ensure the content type is always correct when there is no filename info,
always add the XML header when building sources.
For API compatibility we also have to support the deprecated vfunc too.
Fixes #13
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
libxmlb assumes the result of a gzipped file is XML, instead of checking the MIME type of the decompressed data. This means that .yml.gz files can't be handled by the converter.
The text was updated successfully, but these errors were encountered: