[Pipet Devel] GMS

[J.W. Bizzaro]

Jarl van Katwijk wrote:
> 
> I've been searching a long time for similair projects and now there're two at once..
> nice-n-sweet luxory.

Yes.  We should both be in contact with the Overflow developers, as they are
willing to collaborate in certain areas.

> I'm hoping it will be easy to rewrite the Loci gui to the gms ADM-DFP communication
> api and to replace Loci's Class-system by gms's MO's. As you can see on the gms site
> my gui is quite simple, it uses listing instead of a nice canvas window. But you
> already got the graphics and code done, I wanna use that part.

There are many features that a Loci-like GUI can bring to the project,
features that go well beyond messaging.  If you look through our mailing list
archives:

    http://bioinformatics.org/pipermail/pipet-devel/

>from the last few months, you will see some discussion of these.  One
interesting idea is to use graphical pipes to 'construct a command-line'
statement.  Another is to build a filesystem browser by wrapping some UNIX
utilities.

> | On the other hand, we have been concentrating on developing a nice GUI plus an
> | API for getting several different GUIs to talk to our core.
> Hmm.. sounds tempting :)
> I didn't got the opportunity to have a detailed look at your sources, will do this
> evening.

Again, this has to do with data streaming.

> It sounds like the logical thing to do, but there seems to be one mayor disign diff.
> between the two projects: the system's objects. Gms uses a 'situation-oriented'
> object, every object stores\processes\filters\etc data, depending on the
> function\situation of the object. Loci seems to use a 'function-orientation' why of
> implementing objects, a 'special' store-object, etc. Why did you choose this
> approach? Or am I totally wrong in the way I think Loci works?

I'm not so sure there is a difference.  You're saying that GMS will _either_
store, process, or filter data, depending on the situation, correct?  But does
each object have _all_ of these capabilities?

With Loci, we were trying to classify objects according to function:

    * Executables process data
    * Files store data
    * Directories store files and executables
    * Viewers/visualizers display data
    * Converters/filters change data format or protocol
    * Flow controllers...control data flow

But I wasn't considering the real needs of the core when defining these
things.  Remember, we haven't even looked into what GMS has already
accomplished.  I suppose it may be that each of these has storage
requirements, etc. that may not be apparent to me.

Loci was being built from the GUI on back.  I think, as a result, we have come
up with some good ideas.  GMS seems to have been built with more emphasis on
the infrastructure.  Again, our projects are very complementary.

> Ic. nice feature. What do you think about my idead to attach a GAP to GMS which is
> using the regulair GUI\client API but is in fact a engine which detects high
> fitness structures and applies those to other instances of gms tunning around the
> inet? This would solve the biggest problem that Loci and gms will have once they
> reach production phase, which is that 'regulair' user wont be able to configure
> the dataflow-diagram, it would just be too complicated for them.

I want to look into this and get Brad's opinion, since I'm not entirely sure
what you're talking about.  We have looked into issues of node configuration
with the realization that some 'programs' or constructs built for this system
will be complex.  I think Loci solves much of this problem by saving
constructs, what we call 'Work Flow Diagrams', as XML.  In fact, we are using
XML as a descriptive meta-data for all of our nodes.  This allows Loci to
combine and recombine nodes and save the constructs.  Have you seen some of
our discussion threads about this?

> One thing: what are Loci's? Are they binairies, or scripts? GMS uses dynamic loadable
> binairies, for speed reasons mainly.

Well, I suppose you're asking about the wrappers and not the programs.  Again,
we haven't come up with a standard API for doing this.  What we have done uses
some Python and some XML.  You're absolutely right that C is faster, but
running programs across the Internet tends to take away any advantage that may
give.

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+