[Pipet Devel] GMS

Gary Van Domselaar gvd at redpoll.pharmacy.ualberta.ca
Tue Mar 14 02:22:51 EST 2000

"J.W. Bizzaro" wrote:
> jarl van katwijk wrote:
> >
> > As I mentioned earlier: the first subject of discussion should be the differance
> > between the classes\objects 'filosophy' of both systems.. I think your choose
> > to implement different types based upon functionality isn't the way it should be
> > done. I'm supporting the 'one global do-everything object".
> >
> > I'm very curious why Loci classes are implemented the way they are...


Loci's philosophy follows that of the unix philosophy: one function, one
application.  Sophisticated, distributed data processing is accomplished
by pipelining these 'simple' applications toghether.  The
'all-inclusive' approach that GMS takes for brokering datastreams is
also valid.  One consideration for Loci, however, is that it is intended
ultimately to act as a graphical scripting language for distributed data
brokering.  The processing applications exist already; Loci wraps these
applications, and adds 'extras' to the workpath (like data format
conversion utilities) in order for the data to stream properly between
different applications.  Other 'elemental loci' include data storage
utilities, which can be customized to store an incoming data stream
based on user defined schemas, possibly so that they can process it
further later using non Loci-wrapped processing applications, or perhaps
to view the data with their favorite viewing application. In our world
of computational biology, this is a requirement, so modularity and
simplicity are a big part of the Loci philosophy.

An additional consideration arises from the following scenario: a simple
workflow diagram can be encapsulated into  a 'node' which is itself
capable of being inserted into another workpath, and so on, ad
infinitum.  An apparently simple workpath may be in reality composed of
multiply nested workpaths and can in principle be quite complex.  In
order to minimize bloat, our thinking was to minimize each type of
elementary node to its basic functionality.  

IMHO, I don't think there is a 'right' or 'wrong' way to design the
elementary objects.  This is all good food for thought, and I suggest we
(Loci, GMS, and Overflow) create a discussion forum where we can have
open discussions on the best way to implement this core functionality. 
The Locians are a very open-minded group; thats one of the reasons why
we discussed our project for so long before committing to writing code. 
Lucky that we did, since we have so recently made contacts with such
useful potential allies!

I am currently working on creating a web-based open source development
environment for our organization: bionformatics.org.  It is based on the
sourceforge development environment (http://sourceforge.net).  It is a
sophisticated and very user-friendly environment intended to foster
discussions and collaborations of the nature in which we are currently
engaged.  I can set up a forum for you, Jean-Marc (canadian, yaay;-) and
the locians to hash out the details of our architectures, design goals,
and hopefully generate a powerful collaboration for creating the
sophisticated data processsing environment that we are all so passionate

> Perhaps you can give us a synopsis/summary of the GMS object philosophy.  It
> would then be easier for me to point out differences, because right now I'm
> not so sure how GMS is different.

I can see from the dia flowchart on your homepage that you have a well
thought out architecture for your core operation, but some of the
acronyms are a little too obscure for me. If you could provide a couple
of paragraphs describing the operation of your 'core' for us, that too
would be greatly appreciated.


                                  Gary Van Domselaar
                               gary at bioinformatics.org
                           bioinformatics.org: The Open Lab

More information about the Pipet-Devel mailing list