[Pipet Devel] GMS

[jarl van katwijk]

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

Sure, they seem to have done some work for high performance processing, something I like
to have a good look at.
I also liked seeing they are doing a speech recognision system.. I've already implemented
festival (speech synthesis), and was looking at IBM's viavoice, but an open source speech
recognision system is much better.

>
>
> > 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.
>

I've downloaded the complete archive yesterday.. will read them

>
> > | 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?

Yes, look at the messaging_mobject_structs.h file. Every object has a 'procedure' that can
mutate the data, it has a history-file is which data is stored (upto 32 entries in memory,
beyond this number on disk), etc. Look for yourself :)


>
>
> 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.

Yes, I have these 'types':
    Sensors:     objects that gather datastreams from the outside world into the pipeline
    Collectors: objects that gather datastream outof the pipeline
    Filters:         objects that have no special situation, they are suppost to prosess
data, filter, route, etc.
    Visuals:        object that output datastreams from the system, display it, etc.


> > 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?

Not yet, but I'm sure noirmal desktop users do not want to program\configure their system.
They exspect the OS to 'know' what to do with data(-streams). But again: I will read the
mailing archive :)

>
> > 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.

The plugins are loaded locally, communication between different instances of gms will take
place tru a sensor\visual pair. But having some scripting\XML API will surely be usefull
somehow.

bye,
jarl