[Bioperl-l] Remote BLAST support discussion
torsten.seemann at infotech.monash.edu.au
Mon Feb 13 00:35:06 UTC 2006
> 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)
> --> 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
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
More information about the Bioperl-l