[Pipet Devel] Re: Overflow/Loci/GMS collaboration

[Jarl van Katwijk]

> > Unconnected lines? Like 'deadend dataflows'?
>
> What Loci would do in such a case is try to send the data to a parent node or
> network, instead of just killing the dataflow.  We were going to define a
> 'dead-end' node for when the dataflow needs to be stopped.  Actually the
> reverse is just as valid: unconnected lines stop the dataflow and special
> nodes can send data to parents.  I just chose the former approach because
> unconnected lines in a nested workspace can be mapped directly onto
> unconnected lines on the parent node, which I think is more intuitive.  You
> can see this in the following screenshot:
>
>     http://bioinformatics.org/loci/documentation/screenshots/latest.gif
>
> The red (unconnected) dots in the nested workspace (lower left) are mapped
> onto the parent node (labeled 'composite') and appear as green (connected)
> dots.

Ic, gms is still very simple about connectivity logic, is this area loci is much more
mature.

>
>
> > Likewise, gms has data in 5 types availieble to every node\object.
> > (Raw\string\integer\
> > percentage\boolean). Historic data is cached\stored on disk.
>
> Are you using XML?  What do you think about using it?

Good Thing, I like using standards anyway, and XML seems to be a good candidate for
data-encapsulation. I did not study it yet.
Yesterday evening I did read the Loci, the Overflow and some other projects
documentation b.t.w.

>
>
> > Maybe the person that coded the core of Loci is interested switching from python to
> > C?
>
> Are you saying you want the GUI in C, or that you want Brad to help with the
> core?

the 2nd, coding the core on my own wont go quickly enough.

>
> It's amusing that all 3 projects independently decided to separate the GUI
> from the core.  But if we are to keep the GUI separate, does it really matter
> what language the GUI is written in, or is this a personal preference?

You're correct. As long as corba is used to combine all parts it's better to chose a
language for every part. Pythons can be better for the GUI, C is best for the core and
C++ can be used for a 'detail level'.

>
> I know it seems awkward to have 3 languages.  But I guess we'll have to see to
> what extent our projects will be merged.  If we're looking at a single
> distribution, and Overflow and GMS agree on either C or C++, then we can
> consider C or C++ for the GUI.  But if our projects become separate
> distributions (as with Gnome) that communicate through CORBA, language
> shouldn't matter.

Yep :)