Re: [Samtools-devel] Support to retrieve type 'B' auxiliary tags in SAMtools

On Tue, Apr 3, 2012 at 7:14 PM, Nils Homer <nil...@gm...> wrote:
> I would appreciate other developers comments on this subject.
>
> In my opinion, the main purpose of samtools' C API (along with Picard) is to
> allow programmatic access to the underlying SAM records.  This includes
> centralizing the boilerplate code for the access of the various types and
> objects specified in the SAM specification.  Without these simple functions,
> the utility of the samtools C API is severely reduced.

Sounds good.

> I would like to have support for accessing a SAM optional tag type ("B")
> that was introduced in the 1.4 spec (see:
> https://github.com/samtools/samtools/pull/5). Admittedly, it is simple code,
> but aggregating it within SAMtools removes both the support burden and
> duplicated code from outside projects.

Do you know if this would simplify life for samtools C API wrappers
like pysam etc? i.e. Are they already having to reinvent code to do
these tasks?

> Moving into the future, I would like
> to submit more patches to samtools to provide easier access to the
> underlying data types. For example, an improved SAM Header data structure on
> which merging and manipulating SAM headers is easier (see:
> https://github.com/nh13/samtools/tree/smt_header).

Changes to make manipulating the SAM header text easier within samtools
sound very useful - consider for example updating the 'samtools sort' header.
I will want to update the SAM header's @SQ lines for 'samtools depad' as well.

> I think having external developers submit patches for bug fixes and new
> features removes a lot of the support burden on Heng, as well as involves
> the community in debugging and improving samtools.  My recent patches
> represent an attempt at giving back to samtools, donating my free time to
> improve on the existing code base. Centralizing the API boilerplate code and
> helping Heng with the repository's maintenance seems like a win-win to me.

Well reviewing and merging contributions is still something that will
still be demanding of Heng Li's time - but as more people become
familiar with the code base that responsibility could be shared.

(Having some good unit test coverage would also help if more
newcomers are touching the core code - we don't all know it as
well as he does for anticipating potential side effects etc - see
the other thread [1] )

Peter

[1] Unit tests thread:
http://sourceforge.net/mailarchive/message.php?msg_id=28955184
http://sourceforge.net/mailarchive/message.php?msg_id=29075215
etc