[Pipet Devel] 3/1 and 1/3

[Jean-Marc Valin]

> At the very LEAST, a collaboration should mean that the respective projects
> (Loci/GMS/Oveflow) don't continue development in such a way as to incorporate
> incompatibilities with VSH.  If you're not excited about VSH right now, then
> fine, maybe you will be later.  But you need to...
> 
>   (1) Tell us what features you'll be adding to your program
>   (2) Consider whether or not features will work in the VSH system
>   (3) Be prepared to change your program to incorporate a VSH feature

That's no problem... Overflow is built in a very modular way. All the
functionality is built into nodes (C++ classes). If you don't like some of them,
you just don't use them, but they don't interfere. If you "rm" a library you
don't want, things will still work (without recompiling). The same for the
Overflow types (like neural nets, vector quantizers, ...). As for supporting
VSH, every new feature will simply be a new node in Overflow.


About the architecture... what about this: Everything that's done locally
(including running other exceutables) is handled by Overflow and all networking
stuff would be handled by GMS, which would take care of connecting all Overflow
processes (here I'm talking about "process" in a weak sense) through a network.
This way there wouldn't be any duplication. Also, every node-to-node connection
in the GMS part of the GUI would be assumed to be "network-able".

Concerning the GUI, I don't think it would be hard to plug in what we've got so
far in another app. Or we can just embed the current GUI in the new app using
bonobo. I don't know enough about this to say which is best.

	Jean-Marc

-- 
Jean-Marc Valin
Universite de Sherbrooke - Genie Electrique
valj01 at gel.usherb.ca