[Bioperl-l] results problem with StandAloneBlast

[Sendu Bala]

Chris Fields wrote:
>> Chris Fields wrote:
>>> If you want flexibility or added functionality then you can 
>>> always contribute a patch, such as adding an option for 
>>> filehandles, IO::String, pipes/forks, or whatever you wish.
>> 
>> Well, it wouldn't be a new feature per se, but just changing the 
>> way the modules work under the hood.
> 
> ...
> 
>> I use IPC::Open3 for blasts and have never run into problems, but 
>> it pretty much falls into the 'apt to cause deadlock' camp. It may
>> pass tests on one machine but fail on others... is there any point
>> in working up a patch (would something of questionable reliability
>> ever be committed into bioperl)?
> 
> The main thing you should avoid is major API changes or issues which
> break this module on other OS's.  I'm not sure that StandAloneBlast
> is 'broken' by using a tempfile as the location of the BLAST report.
> 
> 
> 
> Any way you go about it, you'll have to capture the BLAST output as a
> stream and get it to persist in a SearchIO object somehow.  It's can
> be a pretty decent memory hit to keep that report hanging around, 
> esp. if it is larger.

Well at the moment StandAloneBlast runs the blast program and stores its
output to a temp file, then gives the temp file name as an arg to
SearchIO. I (not using bioperl) would use IPC::Open3 to send the output
of the blast program directly to my parser. The question is, why wasn't
this done in StandAloneBlast? I would get the blast program output
handle and pass it directly to SearchIO with the -fh option of new().
The only difference here is it's faster and more efficient with the
direct pipe, but you can't subsequently seek the SearchIO's internal
filehandle (as we discussing in this thread). There are no (additional)
issues with memory.

If it isn't done using IPC::Open3 (or similar) because the original
author already knew it wouldn't be reliable enough, or for some other
reason(s), fine. Does anyone know the reasons?