[Pipet Devel] and another thing...

[J.W. Bizzaro]

To expand upon the Globetrotter analogy, each locus must be aware of the other
loci in the installation, without having anything added to the code.  In other
words, the bball players must be able to handle the addition and subtraction
of other players.

If someone has Loci installed with say 10 tools, and they download an 11th
tool from some third-party developer, the original 10 must know the 11th is
there and what it can do.  And the 11th must know that there are 10 others and
what each of them can do.

This is similar to what I had planned for the Gatekeeper.  The Gatekeeper will
know what tools are installed locally (on the server) and what each can do. 
This information is reported to the connecting client, so that the client loci
will then know what analysis loci are there.  I actually have that expanded a
bit to include a hub server at Lowell (or wherever) that will have all the
Gatekeepers on the Internet registered, so that someone with Loci can see all
of the analysis loci available in the world.

For both the client and server sides, we need databases to keep track of what
loci are present and what they can do.  In the case of the client (GUI) loci,
all of the public objects need to be recorded.  Carlos, does this make sense
regarding Paos?  Paos is an active object server.  Does it have a way to
catalog objects that may change as the configuration changes?  This is VERY important!

Can you guys see now, with this model in mind, just how difficult it would be
to get Loci to operate harmoiously with more than one language at the core?


Sweet Georgia Brown...


Jeff
bizzaro at bc.edu



-- 
J.W. Bizzaro                  Phone: 617-552-3905
Boston College                mailto:bizzaro at bc.edu
Department of Chemistry       http://www.uml.edu/Dept/Chem/Bizzaro/
--