[Bioperl-l] Remote BLAST support discussion
jason.stajich at duke.edu
Fri Feb 10 12:15:17 EST 2006
The reason for suggesting a change has to do with the instability of
the CGI interface/format of the returned data, the text format is not
a stable format from the webserver which reportedly will cease to be
reliably parsed. Yes we can keep hacking the blast parser code to
handle this, but the bioperl release cycle is certainly not tied to
the NCBI blast release cycle so I find it unsatisfying to know that
we are going to have broken code when they change the output formats
(but not know when).
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
In terms of the web-based queues - I think the best change we can
make is have the XML be the preferred retrieval method.
I also see value in providing a wrapper for netblast since it should
look an awful lot like running blast locally.
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!):
--> StandAlone (support for both WU-BLAST and NCBI-
BLAST local binaries and MPI-BLAST too if simple)
--> RemoteNCBI (currently the RemoteBlast server)
--> RemoteEBISOAP (EBI has a nice SOAP interface that
works quite well, but may not provide all the same databases as what
people expect from NCBI)
--> RemoteNetBlast (blastcl3 or netblast local executable)
(other things that people want)
[note: If these ideas are appealing or not, someone should archive
the discussions and discussions on the wiki page so we can rely less
on people searching the mailing archives for how a decision was
made. Perhaps Roger can do this sort of editing in addition to the
planning for support of this module].
On Feb 7, 2006, at 8:38 PM, Paul Boutros wrote:
> Hi Roger,
> I would definitely prefer a fully Perl-based implementation. For
> starters, I have not
> been successful in compiling the Toolkit that contains netblast for
> some platforms (e.g.
> AIX 5.2 w/gcc 4.0).
> I haven't been following the discussion: is there some compelling
> reason to prefer a
> netblast-based system that's come up recently? I'm guessing that
> adding a new non-perl
> dependency would only be done if there was considerable
> justification for this type of
> change, but I'm not clear from your message what that justification
> Message: 12
> Date: Mon, 6 Feb 2006 20:46:44 -0600
> From: "Roger Hall" <rahall2 at ualr.edu>
> Subject: [Bioperl-l] RemoteBlast users - potentially major changes -
> please reply
> To: <bioperl-l at lists.open-bio.org>
> Message-ID: <002001c62b90$bb9dbe00$4301a8c0 at LIBERAL>
> Content-Type: text/plain; charset="us-ascii"
> To everyone who uses RemoteBlast.pm:
> Would anyone object to RemoteBlast being rewritten in a way that
> NCBI's blastcl3 executable?
> Binary downloads of blastcl3 (column "netblast") are available for
> platforms at: http://ncbi.nih.gov/BLAST/download.shtml
> Does anyone require or desire a "pure perl" implementation? If so,
> explain the advantage you see with such an implementation.
> Roger Hall
> Technical Director
> MidSouth Bioinformatics Center
> University of Arkansas at Little Rock
> (501) 569-8074
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
More information about the Bioperl-l