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

[Jean-Marc Valin]

> I read the Overflow documentation, and I'm not very enthousiastic about it. I think

Unfortunatly, the doc is not totally up-to-date and mostly does not reflect wat
*could* be done with Overflow.

> it's structures are to small, it's more suiteble for realtime processing as it is for
> application intergration. Using the Overflow core will requere a lot of
> configurartion before it can do something usefull, even when on got a lot 'subnets'.
> Also its components wont be manageble, they will be in the system in too great
> numbers for a security\authentication system to handle. 2ndly, as I memtioned before
> in some emails, I think nodes of different 'types' wont be as  powerfull as a general
> object type, even when this general type has more cpu\memory overhead. Modern C

Don't confuse node types and data types. Node types just means what the node
does (FFT, OR, IF, exec, ...). You need them (Though if you want to run an app,
you can use the "Exec" node). As for the data types, they all derive from a base
object class, so every node have Objects as inputs and outputs. We use real-time
type identification in nodes to make sure that the inputs are the right type
(eg. the FFT node expects its input to be a vector, otherwise it'll throw an
exception). Out Object type is very similar to Glib's Object, except that we use
some C++ features to do the reference counting and casting automatically
(instead of gtk_object_ref or GTK_OBJECT()).

> programming libraries, like Glib, will greatly remove this overhead anyway. And 3thly
> I dont really like the way Overflow enforces high speed and high configuarability;
> these features should mainly remain inside the wrapped applications themselfs. GMS
> (and also Loci) want to accomplish 'Application Intergration", they dont want to be
> "Doing the work themselfs".
> Having the structures of Overflow inside nodes does make sense, this way it offers a
> methode for writing nodes\plugins in a 'scripting' language. 4thly the gms core is
> gonna be very fast: too, it already executes binairy code instead of some form of
> scripting and I'm gonnan optimize the dataflow prosessor a lot.  So there's no need
> to chose  the "overflow way' for speed reasons.

When I say fast, I mean that Overflow is capable of running ~50,000 simple nodes
per second - and that's barely enough for what I do (we're working on making it
faster). Just a fork or opening a socket is orders of magnitude too slow.

Also considering remote execution, it's a nice thing to have, but it's not
something you're going to use all the time. I wonder what a simple RSH node (~15
minutes to code) in Overflow could do...

As for the name, vsh (although it exists - but dead) would be nice... Besides
that, the reason we chose Overflow is that ObjectFlow, gFlow, VisualFlow, ...
were all taken.

	Jean-Marc