In #456, the output path is open as a normal stream independently of the extension and does not have any extra feature (just a plain output). As it is an experimental feature, we can change quite a lot until we release to beta. The following improvements come to my mind:
Choose a coordinate-based format that could be used with htsjdk to read/write (codec-implementation). For example, using BED-like output is nice, but there are other formats that might be useful and easier to parse: e.g., some annotation format (gtf/gff). As we are using TableFeature, there is already a codec for it - but maybe it is not ideal.
Related with the previous, we can allow indexing for fast retrieval (e.g, tabix).
Allow compression in any format, including bgzip, based on the output extension. This will make the format consistent with the output. It is also a requirement for tabix indexing.
In #456, the output path is open as a normal stream independently of the extension and does not have any extra feature (just a plain output). As it is an experimental feature, we can change quite a lot until we release to beta. The following improvements come to my mind:
TableFeature, there is already a codec for it - but maybe it is not ideal.For writing tribble/tabix properly, my proposal in https://github.com/samtools/htsjdk/pull/822 would be nice to support out-of-the-box all this features properly.