[Pipet Devel] Another XML proposal - Part 3.

J.W. Bizzaro bizzaro at bc.edu
Mon Apr 5 10:53:45 EDT 1999


Humberto Ortiz Zuazaga wrote:

> > Hmmmm.  Either way, we're still talking about transferring a script.
> 
> Perhaps not.  Say I'm doing an analisis on a locus that returns multiple
> alingments.  I get my results back with the url for a multiple sequence
> viewer, but I already have one installed from a trusted source.  I won't need
> to get a new one.

I agree.  The local app broker should keep a cache of viewers, perhaps a
permanent repository if the source is trusted.  (Hmmm!)  There is no need to
keep downloading the same information, especially if it is large.

So maybe the remote app brokers can say, "Here is the XML for the biodata and
workflow.  Oh, and here is where you can get the GUI IF you need it."

An alternative might have been for the local app broker to tell the remote app
broker that it has the right viewer.  But if you think about it, how would the
local app broker know what GUI the returning biodata would need.

> > I wasn't talking about anything that would require a DTD, just a marker to say
> > <thescript> </thescript>.
> 
> But that's what I mean.  What does <thescript> have to do with describing
> nucleotide sequences?

This has to do with embedding the GUI script.  The markers could be just like
those used to embed a script in HTML, like Javascript.  I wasn't talking about
biodata there.

> > Security is an issue for executing _any_ code from a remote source, whether or
> > not it happens to be in the same file as the XML.
> 
> Presumably, any loci shipped with the Locus distribution are safe.

But those from LOCI.SOMEURL.NET may not be.

> I say all loci should return results that say "This is valid bicml nucleotide
> sequence v4.2"
> 
> I don't want a locus to say "Best viewed with Internet Genome Explorer 10.3".

But you do want the remote app broker to suggest a viewer?

> No, I specifically think putting the UI code into the data stream is bad.
> After the first time I get the UI, why should I keep downloading it?  Imagine
> having to download netscape everytime you wanted to view a html file.

I get your point, although I hope our GUI scripts are never that big ;-)  In
some cases the GUI script will be as small as a Javascript.  In fact, in most
cases it should be that small.  This is why the GUI widgets will be very
high-level.

I have never heard complaints that Javascript is too much to download and that
they should be cached.  If we can make it that small, embedding the GUI should
be reasonable.  If we cannot, we should go with some system for determining
whether or not the GUI is needed.

> As a matter of fact, an analysis locus doesn't even have to publish the url
> for a display locus in every result, we can use the AppBroker (can we call her
> the Matchmaker instead? she facilitates the exchange of loci) to keep track of
> where to get a display locus for the results.

You mean the local app broker?  I was calling it Techie, but Matchmaker is
applicable to all app brokers.

> So if I write a new analysis locus and want to make it available to the
> community I can publish the location of the analysis locus (source or service)
> and the output formats.  Display loci publish the input formats they support,
> and the AppBroker can make sure your workspace has the appropriate display
> locus, or help you locate one

Yep.

> or find a translation locus that can do the
> conversion for you.

What conversion?  Are you talking about converting the biodata XML or the GUI? 
I suppose the former.


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



More information about the Pipet-Devel mailing list