same signature for Chunks() csi and tabix

[brentp]

having an external library support both csi and tabix would be simpler if they both had the same signature for Chunks() would you consider changing CSI to signature of

func (i *Index) Chunks(r Record) ([]bgzf.Chunk, error)

to match tabix?

[kortschak]

I think this is reasonable, but I'm reluctant to keep changing API. If we can sort out what changes need to be made then do them all at once, followed by a stability guarantee, then I'm OK with it.

The Record type would probably want to be in a common package, but I don't see where. Where would you propose it go? One possibility is to uninternalise internal as index and place it there.

[brentp]

seems a shame to rename internal just to expose a single interface. But, assuming you dont want to import tabix into csi, I dont see a better alternative.

[brentp]

I guess it could go in bgzf

[kortschak]

I thought about bgzf and it's not the right level of abstraction.

Are there any other API changes you'd like to see?

[brentp]

Not that I've noticed.
Anything that would be needed to be moved for cram?

[kortschak]

I try to avoid thinking about CRAM.

Looking at the signature of tabix and csi Chunks methods, they cannot be merged. One takes an RID integer and the other takes a string. The csi Chunks method could be altered to take a csi.Record, but I don't really see the benefit in that. Can you explain to me what you want out of this?

[kortschak]

It seems to me that the change should be in tabix. bam and csi take ref, beg, end, while tabix takes an interface that can give these values. Having it take this interface value in hindsight is odd.

[brentp]

I was thinking if I had

type Indexed interface {
    Chunks(???) []bgzf.Chunk
}

then I could support both tabix and csi with little code change after I had the index read in. I'm fine with a change to tabix instead, I just figured a change to csi would affect less external code.