[Bioperl-l] Remote BLAST support discussion

[Torsten Seemann]

> Mostly I think we need to try and support something that will  
> "ALWAYS" work so that individuals setting up webservices which rely  
> on remote blast functionality.  In theory, netblast/blastcl3 should  
> always work since NCBI has to update the exe when they change their  
> server setup.

What usually happens when an older 'blastcl3' binary is used on a newer
server setup? I guess it fails in a deterministic manner so the BioPerl
user can throw a useful exception.

> I also see value in providing a wrapper for netblast since it should  
> look an awful lot like running blast locally.

Agreed - they are virtually indistinguishable.

> Ideally I'd like to see a more extensible system, something like (and  
> please feel free to come up with better names for the modules!):

Do BioPerl coding standards require "::Blast" over "::BLAST" ?
(not important anyway)

> Bio::Tools::Run::Blast
>   -->             StandAlone (support for [..as many flavours as poss])
>   -->             RemoteNCBI (currently the RemoteBlast server)
>   -->             RemoteEBISOAP (EBI has a nice SOAP interface that  
>   -->             RemoteNetBlast (blastcl3 or netblast local executable)
>   (other things that people want)

Looks reasonable. I assume there's some interfaces in there like
Bio::Tools::Blast::BlastI etc.

Could probably call "RemoteNetBlast" just "RemoteNet" because it is
already in the Blast:: namespace. (not important though)

My only suggestion for StandAlone (and RemoteNetBlast) is that they both
do a generic "run a local binary with env. vars and parameters and
capture the stdout, stderr and return code". This needs to be abstracted
away (or re-use existing code from bioperl-run?). Jason mentioned
Ensembl::Runnable as a source of code we could incorporate into Bioperl.

-- 
Torsten Seemann <torsten.seemann at infotech.monash.edu.au>
Victorian Bioinformatics Consortium