[Pipet Devel] Project Design (fwd)

Brad Chapman chapmanb at arches.uga.edu
Thu Mar 23 14:56:44 EST 2000

Hey all;
	This is from a discussion Jarl and I were having, and I thought it
was really relevant to everyone. I like this plan for integrating
everything--whadda you all think?


---------- Forwarded message ----------
Date: Thu, 23 Mar 2000 19:45:42 +0100
From: jarl van katwijk <jarl at casema.net>
To: Brad Chapman <chapmanb at arches.uga.edu>
Subject: Project Design

> 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
to this:

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

More information about the Pipet-Devel mailing list