[Bioperl-l] Remote BLAST support discussion

[Chris Fields]

> -----Original Message-----
> From: bioperl-l-bounces at lists.open-bio.org 
> [mailto:bioperl-l-bounces at lists.open-bio.org] On Behalf Of 
> Jason Stajich
> Sent: Friday, February 10, 2006 11:15 AM
> To: Paul.Boutros at utoronto.ca
> Cc: BioPerl Mailing List
> Subject: [Bioperl-l] Remote BLAST support discussion
> 
> Paul -
> 
> 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 server setup.
> 
> 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!):
> 
> Bio::Tools::Run::Blast
>   -->             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)

Sounds good to me.  I think any wrapper for netblast could most easily be
based on StandAloneBlast; the parameters look pretty much identical, though
it'll probably need a little configuring as a quick text search through
StandAloneBlast didn't show any 'xml' tags.  Roger seemed to agree on this.
 
> [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].
> 
> -jason
> 
> 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 is.
> >
> > Paul
> >
> >
> >
> > ------------------------------
> >
> > 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 
> > requires NCBI's blastcl3 executable?
> >
> > Binary downloads of blastcl3 (column "netblast") are available for 
> > numerous platforms at: http://ncbi.nih.gov/BLAST/download.shtml
> >
> > Does anyone require or desire a "pure perl" implementation? If so, 
> > please explain the advantage you see with such an implementation.
> >
> > Thanks!
> >
> >
> > 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
> > http://lists.open-bio.org/mailman/listinfo/bioperl-l
> 
> --
> Jason Stajich
> Duke University
> http://www.duke.edu/~jes12
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l

Christopher Fields
Postdoctoral Researcher - Switzer Lab
Dept. of Biochemistry
University of Illinois Urbana-Champaign