[Pipet Devel] from Justin

[J.W. Bizzaro]

Humberto Ortiz Zuazaga wrote:
> 
> I think Lincoln Stein's boulder file format is a good example here. In
> the documentation he suggests that programs doing io on boulder files
> should ignore and pass through any records it doesn't understand.

Do you have a reference or URL for this?  I do understand what you're
suggesting.

> an analysis locus should say "I need v3.2 foo objects as input" or
> return a list of acceptable input formats. If your local locus can't
> export that format object it should request the services of a
> translator. The locid can perhaps modify the dialog if it already has
> translators available.

Interesting.  It seems as though we have to choose between 3 controllers.  Who
makes the final decision about components to be added to the workpath?

    (1) The locus
    (2) The server/locid
    (3) The user

Maybe we can choose a chain of command, as suggested by the order of the list:

    (1) The locus tries to find an immediately available solution

             if that fails...

    (2) The locid tries to find a remotely available solution

             if that fails...

    (3) The user is notified

There is a difference, however, in how we see the locus functioning.  I think
you're saying the locus waits until _runtime_ to check for availability, when
the next component in the workpath is needed.  It then decides on its own what
to do next.

But I'm saying that this should be decided at _design_time_, and ultimately by
the locus developer.  There are a several advantages to checking availability at
design time:

    (1) The workpath and all components can be displayed in the WFD
    (2) The workflow won't be interrupted constantly at runtime
    (3) The developer has more control
    (4) The locus will require less "AI" to make decisions.

So the chain of command would be more like this:

    (1) The locus finds all immediately available solutions
    (2) The locid finds all remotely available solutions
    (3) The developer is given a list and decides what to do next

What I'd like to see is the locus respond ("I need v3.2 foo objects as input")
to the Workspace at design time to let the developer know what is needed.  Sure,
it's simpler not to get the user involved in this, but we are talking about a
developer constructing a command-line, something that may not be done by
everyone.

But the strongest argument is that design-time availability-checks match my more
recent thinking about the use of the GUI for both analysis _and_ locus
construction ;-)  I hope the GUI can represent, as well as allow for the control
of, every Loci component.


:-)
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro at bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--