[Pipet Devel] Another XML proposal - Part 1.

[Humberto Ortiz Zuazaga]

> > but rather than having a bunch of
> > hardcoded loci types, we can query the locus for it's interface (of course
> > we'll want to cache interfaces).
> 
> Ohhh yes!  This is the database I was just talking about.  Maybe it's a part of
> the benchtop, but it keeps track of all loci available to the user and what they
> can do.  But instead of the locus being queried when it is about to be used, it
> is queried when it becomes accessible to the workspace.
> 
> This is important for hot-plugging loci.  The user can add loci while Loci is
> running.  Maybe at a certain time interval, the workspace (database part)
> queries all accessible loci, and the loci return values informing the workspace
> what they can do.

Yes, this is good.  Installing a display locus (from wherever, more on this 
later) should register the locus as able to display a certain set of DTDs, or 
an analysis locus can register the type of analysis performed and the input 
and output formats it handles.  Once registered, the workspace can find these 
locally and dispatch them immediately.

The app broker locus can also be queried at run time to find display loci or 
analysis loci meeting certain requirements.  Perhaps the workspace could ask 
the app broker to find source for a widget to display frobnicated sequences.  
This source could then be downloaded and registered locally.

I could set up my app broker to only accept source loci from "trusted" 
sources, or to only send my data to trusted analysis loci.  If I were really 
paranoid, I could turn off the app broker, and only run locally registered 
loci.

Is the locus database different from the app broker, or can they be merged?

The trick then is how the app broker finds out about loci at remote sites.
-- 
Humberto Ortiz Zuazaga
Bioinformatics Specialist
Institute of Neurobiology
hortiz at neurobio.upr.clu.edu