[Bioperl-l] Bio::SeqAnalysisParserI [was: Bio::Tools::HMMER refactoring]

[Ewan Birney]

On Mon, 18 Dec 2000, Hilmar Lapp wrote:

> Ewan Birney wrote:
> > 
> > In addition, this interface will not go easily into a corba
> > /time-sliced/threaded framework.
> > 
> > Why not have
> > 
> >   Bio::SeqAnalysisParserFactoryI
> > 
> >   $parser = $factory->create_parser(-fh => \*FILE);
> > 
> >   Bio::SeqAnalyisParserI
> > 
> >   while( $next_feature = $parser->next_feature ) {
> > 
> >   }
> > 
> > same number of functions defined. Twice the number of interfaces, but
> > these are the interfaces I would argue we want.
> > 
> > An implementation could implement ParserFactoryI and ParserI in the same
> > module if so wished.
> > 
> > Whaddya reckon? Too complex for your taste hilmar?
> > 
> 
> Well, Jason and I had such a layout in mind first, but the question was
> how significant the performance hit might be in a CORBA context. A
> likely situation is that you have less than 10 methods for which you
> need parsers, and thousands of sequences, that is, thousands of inputs
> for each parser. We thought that in a CORBA context creating 10 objects
> instead of 10,000 does matter (in pure Perl you probably wouldn't notice
> a difference), and that therefore we wanted to be able to reuse a
> once-created parser object.
> 
> Of course you could let the parser implement the factory, too, and abuse
> it as a 'reset', but IMHO this is abuse.
> 
> So, what I wanted to say, I guess both Jason and I are in principle
> happy with a factory. Based on my experience with CORBA, however, there
> is a performance issue, but my experience is somewhat not up-to-date,
> and not that extensive, so it's up to you and Jason to make a decision
> here.

From a CORBA perspective I think both schemes would be implemented
similarly, but with teh current scheme being less clean - indeed -
potentially dangerously assumming a single client, single thread mode.

The overhead is going to be in making the SeqFeatures in a CORBA contex,
not the analysis routines. The analysis routine creation only becomes a
bottleneck in certain cases (though this does happen - for example, we
have hit this bottleneck in Ensembl...)


So - we are ok in splitting the interfaces into two now? Final thoughts
from jason?



> 
> 	Hilmar
> -- 
> -----------------------------------------------------------------
> Hilmar Lapp                                email: hlapp@gmx.net
> GNF, San Diego, Ca. 92122                  phone: +1 858 812 1757
> -----------------------------------------------------------------
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------