[Bioperl-l] Pise/bioperl

[Jason Stajich]

On Thu, 10 Jan 2002, Catherine Letondal wrote:

> Ok, but why having different method names (align, search, analyze, ...) for running
> the analysis? Why not just run (for instance)?

No you're right that is probably more coherent.  Possible that different
types of 'run' are needed which can't always be deduced from the
input data - haven't really thought about this very much so perhaps I am
just causing problems where there are none.

>
> > Obviously I am simplifying what is a more complex problem. But
> > the idea is there and I feel like it would be something to debate.  I only
> > want things to be fairly transparent to the user whether or not invoking
> > an application requires submitting a HTTP request through LWP or through
> > CORBA or as a forked process.
>
> I just wonder - Bio::Factory::PISE looks like a broker? What should
> @params be in:
> 	new Bio::Factory::PISE(@params) ? Am I still able to choose a
> given Pise server? (e.g a fast one versus a slow one, etc...). Am I
> able to choose different servers for different kind of programs? Or to
> choose different servers for the *same* program (if I want to run
> several jobs in parallel)?  (cf
> http://www-alt.pasteur.fr/~letondal/Pise/PiseBioperl/Examples/parallel.pl)
>
params could be
username/password
Which server (override the default server URL)
Proxy information
etc.. everything needed to setup a connection to a site.

For a CORBA server implementation it would be the part where the ORB was
initialized, the IOR retrieved and/or specified.

>
> > You have a the JobQueue notion built into PISE, I think this is probably
> > better than my very simplified example above.
>
> A JobQueue? What do you mean?
>

By that I mean asynchronous mode.  So submitting a bunch of jobs and
having the potential to retrieve the results later.  Sort of like how we
can submit BLAST jobs to NCBI queue and retrieve the results later
(perhaps after polling the server periodically to see if job is finished
or just waiting a specified amount of time).

> > We might add a parameter to
> > the server or application code that is BLOCKUNTILFINISHED so that users
> > don't have to write while( ! done() ) sleep(X)
>
> There are indeed 2 different methods: submit (asynchronous) and run
> (waits until completion).
>
>     my $program = Bio::Tools::Run::Pise::program->new (...);
>
>     # run: submit and waits for completion
>     my $job = $program->run();
>
>     # for long jobs
>     my $job = $program->submit(); # only submit the request
>     return $job->jobid;
>
>     # later, from another place
>     my $job = PiseJob->fromUrl($jobid);
>     if ($job->terminated) {
>        print $job->stdout;
>     }
>

Right - I think we can mimic synchronous behavior in an asynchronous
mode for a user by hiding the polling to see if job is finished.
Sometimes people know that a particular analysis is a rate limiting step
so we might want to support the notion of telling the application layer to
block until the result is ready.

-j

> --
> Catherine Letondal -- Pasteur Institute Computing Center
>

-- 
Jason Stajich
Duke University
jason@cgt.mc.duke.edu