> > > > The reason I was suggesting the Overflow core is that we already handle IO with > > files and pipes, so Overflow nodes can also be executables (it's tested and it > > works). From what I know now, I see two options: > > 1) Wrap all Overflow as a Loki/GMS node > > 2) Use Overflow's core and implement the missing functionnalities. > > If we chose 2), what would we use GMS's core for? I'd like to hear Jarl's > thoughts on Overflow's core. GMS may provide the missing functionality for > Overflow, and merging C and C++ shouldn't be all THAT difficult. I was > thinking about 1), but sure, we should consider 2) as well. I read the Overflow documentation, and I'm not very enthousiastic about it. I think 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 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. Dont take me wrong, there's surtainly a lot that the 'overflow-way' can do, but I think it's not a good base for application intergration. > > I forgot... another thing we have in Overflow that's essential (well, for what I > > do with it) is the ability to "automatically" cache the results that will be > > reused in another iteration of a loop or by another node, so nothing gets > > computed twice. > > I haven't even thought about that, since we haven't developed any flow control > nodes for Loci. Loci does, however, always keep reference to the location of > a block of data (often kept as 'document' nodes) so we probably wouldn't have > thrown that stuff away. > GMS also does keep track of histori data. Calculation results reusage is a nice idea..