[Pipet Devel] Idl

[jarl van katwijk]

> >     My question is, do we really need this level of control so that
> > someone can manipulate a process so much while it is running?
>
> I for one am very much in favor of this level of control.  As computational
> biologists, we may be working on analyses involving terabytes of data and days
> of calculations.  Should the network just sit there unusable during these
> analyses?  Should entire jobs be scrapped if it turns out one node needs to be
> moved?
>
> I think this level of control is akin to the use of threading in an
> application.  If threading is not used for compute-intensive tasks, the GUI
> freezes up and the application is unusable.  Sure, it's still running, and you
> can always stop it.  But the loss in usability is both perceived by the user
> and quite real.
>

For all non corba techies: the DL (or gui) is corba based, this means the DL runs

as a seperate application, and never freeses. Calling a corba function will
always
have a response, so it is the non-threaded corba server (the BL) that would
freeze. This freeze will only take as long as the processing that corba call will
take,
being a few nano seconds.

>
> > For the following functions--do we need the processor to know about
> > the description of the program? Can all of this type of information by
> > stored in xml in the "middle scripting thingy"?
>
> This is mostly useful to the user and should be kept as XML meta-data.  I
> don't know what use the core has for it.

The 'description' is merly a identification for the security meganism.

>
> The back-end or applications should set the status, which is reported back to
> the user through the datastream.

Also. But the DL must be able to modify the status of a node\subnet too.
This wont happen too often, but things like renicing or stalling will be needed.

>
> Hmmm.  I have been in favor of the GUI allowing only compatible connections
> (same data type).  If we assign types (e.g., mime) to data, we can determine
> what will and won't work.

The BL will be able to marchall (data conversion). This wont conflict with the
type-casting
the PL has, the marchalling will be like manipulating High-endian\Low-endian
formatting,
plain-encrypted formats, etc.

>
> > For the following, do we still need the processing engine to store a
> > log/history of events, or should this be handled by the middle
> > scripting part, which can maintain logs for all its communication.
>
> We can make a 'front' that records the datastream to a file.

The BL (gms) already does this (see messaging_mobject_structs.h -> histryIO)
But logging the PL nodes wont be touched by this. This should be optional,
because logging every node will have huge CPU load.