[Bioperl-l] 1.01

[Heikki Lehvaslaiho]

Jason Stajich wrote:
> 
> On Mon, 13 May 2002, Catherine Letondal wrote:
> 
> >
> > Jason Stajich wrote:
> > >Some projects on the table that one might hope would be part of 1.2:
> > >[...]
> > > * Design the interface based on the Bioperl/PISE to describe
> > >   remote analysis queues and add those classes to the main trunk.  Use
> > >   this interface for local execution as well as remote.
> >
> > Hi,
> >
> > Is it time to start discussions? I don't know exactly what questions are to be discussed
> > yet? Anyway, these are my questions and suggestions ...
> >
> 
> Yes, it is time if people are willing to code it - I have to admit - I'd
> like to push back from the table wrt to designing this and let someone
> else take the lead.
> 
> I think you've already done a great deal of the work or attatching to the
> PISE system so I'd like to adopt as much it as possible. I think all the
> great stuff you outlined below is what we need.  Can we define some
> interfaces that meet these specs.  I also hope that Martin would be
> interested in making sure this will sync up with the openBSA/Novella
> interface.
> 
> Shawn and Jerm have been working on interfaces to Phylip apps so would be
> a cool test to build the interface to these as local and remote and see if
> we can just toggle a remote/local flag and get the script to work in both
> cases.

Emboss is distributer with version of PHYLIP (It is major part of so called
EMBASSY programs, which means that these programs have slightly different
licencing policy and their authors want the them to retain their independent
identity.) 

It would be great if the same Bioperl code could be used to talk to 

1) Original, local PHYLIP
2) local PHYLIP through EMBOSS interface
3) remote PHYLIP using PISE


> > 1) creating the factory and running:
> >
> >   # a) analysis queue (returns a Bio::Factory::Pise)
> >   $factory = new Bio::Factory::EMBOSS;
> >   # or:
> >   $factory = new Bio::Factory::Pise;
> >
> >   # b) analysis application object (returns a Bio::Tools::Run::PiseApplication or
> >   # Bio::Tools::Run::EMBOSSApplication)
> >   $mfold = $factory->program('mfold');
> >
> >   # c) analysis results
> >   $result = $mfold->run();
> >
> >
> >   ... is that OK for EMBOSS and openBSA?
> >
> Sure - openBSA is probably richer about what it allows you to do in terms
> of checking to see what the status of the job is.  Not important here
> other than the ability to either send a job and block till a result is
> returned or queue up a set of results and then polling the server at later
> point for the job id status.  The RemoteBlast object could be assimilated
> into this behavior as well.
> 
> >
> > 2) general execution parameters:
> >
> >  a) local or remote execution
> >       - default could be local for EMBOSS and remote for Pise?
> >       - in Pise, the default remote server could be different for different programs (I
> >       mean, not only at Pasteur...:-) )
> >
> >     - so one should be able to choose between local/remote execution and, if remote, to
> >    choose a non-default server location; this choices could happen either at
> >    factory creation, or at application creation, or at run step:
> >       # a) at factory creation
> >       $factory = new Bio::Factory::Pise(-remote => 'http://somewhere/cgi-bin/Pise');
> >
> >       # b) at application creation - take the default remote server
> >       $needle = $factory->program('needle', -remote => 1);
> >
> >       # c) at run time
> >       $result = $mfold->run(-remote => 'http://bioweb.pasteur.fr/cgi-bin/seqanal/mfold.pl');
> >
> Exactly!
> We may want to fold this into some of the new Bio::Root::HTTPget so one
> can use proxies for  those behind firewalls.
> 
> >
> >  b) email could be specified once at factory creation (for Pise)
> >
> sure.
> >
> > 3) parameters specification
> >
> >    a) when?
> >       # at factory creation?
> >       $water = $factory->program('water', sequencea => $seqa,  seqall => $seqb);
> >       $result1 = $water->run();
> >
> >       # before running?
> >       $water->sequencea($seqc);
> >       $result2 = $water->run();
> >
> >       # when running?
> >       $result3 = $water->run(sequencea => $seqd);


The primary way of action has to be before running but it shoud be possible
to have an interface for passing tyhe arguments to the factory which then
passes them on to the application. 


> as part of running I guess - but one might want to be able to set some
> parameters in the factory objects like
> $factory->db('est');
> foreach my $seq ( @seqs ) {
>         $result2->run(-sequencea => $seq);
> }
> So setting it in the factory would account for a default behavior in
> calls? Or is this making it too complicated?

No. This is exactly how it should be. Currently only option 'auto' is edded
automatically to the commandline, for most sequence feature related 
programs it should also add the default output format which should be GFF.
These parameters should not be hard coded but resettable at the factory
level.

In case you have not noticed, Luke McCarthy has released his perl based GUI
to EMBOSS. I was planning to see if could include his ACD class into Bioperl
but that have to wait until I get my laptop probelm sorted out.

See: 

The GUI can be downloaded from http://bioinfo.pbi.nrc.ca/~lukem/EMBOSS or
http://www.cbr.nrc.ca/EMBOSS and a demo version is available online at
http://bioinfo.pbi.nrc.ca/cgi-bin/emboss-redirect.pl


	-heikki