What should the API for BAM slicing look like?

[seandavi]

• Should it mirror reading from a local BAM, in a sense?
• How should paired-end data be handled?

[mtmorgan]

Currently I think slicing() should return a path-to-file, kind of consistent with how the other functions deal with the return values -- list-of-lists, etc. I think the higher-level return should be GAlignments(List)?() with paired-end data handled automatically.

[lawremi]

Would be nice to have a filter for concordant pairs, in which case it would return a GAlignmentPairs. Not too hard to implement post-hoc, but probably worth having in the API.

[seandavi]

Does the higher-level functionality belong here, or should we start another package?

[lawremi]

What higher-level functionality specifically?

[seandavi]

After accessing data with the current package, the data need to be pulled into R. The process of pulling data into containers, be it reads, variants, or other tab-delimited files is what I mean by higher level functionality. I lean toward building that functionality into this package, but I thought I would ask. The other approach is to keep the API client clean and separate and build one or more new packages.

[lawremi]

I guess if the data are arriving in some format that is relevant in other contexts, then we should put the parsing/import code somewhere else, like GenomicAlignments or rtracklayer. But if it's specific to this API, then it's probably OK to keep the code together for now.

[seandavi]

Thx.