[Pipet Devel] Project Design (fwd)

[Jean-Marc Valin]

> > Well, the only think I worry about is that Overflow probably doesn't
> > want to be "absorbed" into GMS and would like to be able to work
> > independently. Couldn't the authentication go in a
> > "processing/pre-processing engine" that then directs stuff to either
> > GMS or Overflow?
> 
> I know the Overflow people dont want their code integrated, but I'm
> saying
> to this:

Depends on what you mean by integrated. 90% of Overflow is just a library.
You're actually probably better use that library in GMS instead of the
executables. If you call that integrating Overflow in GMS, well fine, If you
want to wrap the executable, fine too (though I don't think it's the best way).
If you want to take some chunks of code and put that in GMS... have fun(good
luck)!

My only constraint is that I want to be able to use Overflow as a stand alone
application.

> 
>                                     Loci based GUI
>                                             |
> -> Communication SAME AS current Loci's GUI, only enhanced
>                                             |
> with various extra gms & overflow features.
>                                            \/
>  Scripts -----> 'Brad's Interperter' :-)


Speaking of interpreter... I was planning on implementing an Overflow node that
uses the Octave interpreter (actually, only the octave library)...


>                                             |                    ->
> Translates scripts\GUI calls to 'gms api+', which will be a reviced
>                                             |
> gms api + the current Overflow api. So gms will select what calls
>                                             |
> are to be handled and which ones are to be passed to overflow
>                                            \/
> Remote Env.---> GMS based broker --> Remote Environment
>                                             |                     -> This
> communication is THE SAME as subnet-subnet comm.
>                                             |
> AND as Oveflow-GUI comm. GMS will emulate that api
>                                            \/
> Local Env.----> Overflow based processor ---> Local Environment
> 
> SO Gms will be adjusted to 'speak' to overflow, overflow stays the same
> as it is, only restricted to local
> operation. And the Loci GUI will stay the same.
> 
> Every body happy?
> 
> > This way, this engine can work with only GMS or only
> > Overflow, if a user desired.
> >
> > > Hmm.. I should read (again) the documentation about the
> > > "pull data flow model", cant place the name now.
> >
> > The Overflow guys just call it "pull technology." Basically, it is
> > just a recursive call to getOutput() starting at the last node in a
> > series and propogating forward to the top node.
> 
> Currently gms processes one data-event at a time, so a data-chunk
> passed the whole structure before the next is prosessed. This will
> have to change to better 'all at once'  processing.

OK, there's not much technology in "pull" :-)... The idea was that you only
compute what's needed. Also, since we also have loops (even loops withing
loops), we must handle the fact that somethimes (well always) one iteration need
data that comes from a past iteration (even future sometimes, though it's not
any harder). The the recursive getOutput() is the only way to handle all the
dependencies correctly. The other advantage is that it doesn't require any kind
of "job dispatcher". You call getOutput() on the last node, and all the requests
will propagate until you have the answer. A node needs only be aware of the
nodes connected to its input, there's no need for anything "global".

	Jean-Marc

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