[BioLib-dev] R: [emboss-dev] EMBOSS 6.3.0 released - SAM/BAM

[Pjotr Prins]

On Fri, Jul 16, 2010 at 08:59:22AM -0500, Chris Fields wrote:
> I agree, but it is worth noting there are Perl/Java/Python bindings
> to the Samtools API already available (both high- and low-level API,
> via Lincoln's Bio::Samtools).  I would be very surprised if there
> isn't a Ruby one available or on the way.  Inclusion of
> EMBOSS-specific functionality (over that of Samtools) would be a
> nice benefit/selling-point.

Only problem, as you may agree, is that this is a Perl XS binding. XS
is hard to do, hard to maintain and these modules tend to suffer from
bit-rot. Providing bindings for different languages is duplication of
effort. 

> I also think sticking with low-level API bindings to a single C
> library is the way to go, keeps things much simpler and more
> portable.  If user-needed (or Bio*-requested) functionality is
> additive to the the EMBOSS (or whatever) C API for SAM/BAM then it
> probably either belongs in another set of common BioLib API bindings
> (GATK was mentioned by Jan) or it's a higher-level feature for the
> languages/Bio* to implement.  I wouldn't want to create an
> all-in-one next-gen package that requires many possibly in-flux C
> APIs, I could see that rapidly becoming a maintenance nightmare.

The way I see it is that we have the upstream package - which ideally
should support basic functionality. If someone feels that there is
more functionality possible, and the upstream author does not want
it, we can create a separate initiative and map that too. It can be a
separate repository/project connected to Biolib.

Biolib is glue.

I agree no real functionality should go into Biolib itself, when
possible. BioLib has a single purpose: bind against different languages,
with testing, documentation and ultimately deployment.

Pj.