[Bioperl-l] remote blast update

[Hilmar Lapp]

"Chervitz, Steve" wrote:
> 
> The BlastIO stream system would also have to differentiate on the type of
> Blast object you want to build (lite or heavy or whatever). So perhaps you'd
> have BlastIO/ncbi and BlastIO/ncbi_lite.

Hi Steve, great to have you back in the discussion. As for heavy
vs light objects, I'm not sure you really need to have multiple
classes here. The things I see that make the difference between
heavy and light are

-  heavy = extended (as opposed to basics everyone needs)
functionality in terms of what is parsed and turned into
retrievable information. This can be heavy in terms of both
performance and code complexity. I think one can solve it by
making the extended parsing switchable, and separating out the
corresponding code into their own methods. An example for what I
mean is the HSP tiling (which I find especially useful, in fact
essential if you want to retrieve %coverage.)
-  heavy because of non-parsing functionality needed only by
special client applications. This can be separated out into a
derived class, or a consumer class (I'd prefer the latter). An
example for what I mean is HTML table generation; as for the
consumer class, you can have a class taking a Blast object and
producing HTML.

Does this make sense?

> 
> Having a set of standard interfaces such as BlastReportI, BlastHitI,
> BlastHSPI that define core functionalities for these objects is also a great
> goal. It would permit more code-reuse, allow users to easily play with
> different implementations, and make life easier in the CORBA world.
> 

I don't think these interfaces need to be specific to Blast, but I
may be missing something. Aaron I think made a shot in this
direction. Have you checked the (incomplete) stuff in
Bio::Search::* ?

As for the BioCorba-bridged Blast-parser discussion, I think it is
absolutely essential to have a Perl-based Blast-parser in BioPerl.
Code-reuse between languages via a Corba bridge is a nice idea,
but IMHO it becomes most useful not by having your text files
parsed by other languages, but by language-independent clean and
consistent interfacing to analysis and database engines (submit an
object, get back the result as an object). Your mileage may vary.

	Hilmar

-- 
-----------------------------------------------------------------
Hilmar Lapp                              email: hilmarl@yahoo.com
GNF, San Diego, Ca. 92122                phone: +1 858 812 1757
-----------------------------------------------------------------