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

[Chris Fields]

On Jul 16, 2010, at 9:48 AM, Pjotr Prins wrote:

> 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. 

So this would also argue for possible BioLib bindings to SamTools, correct?

>> 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.

Makes sense to me.

chris