[Pipet Devel] Piper design issue

Jarl van Katwijk jarl at xs4all.nl
Wed Mar 21 20:01:49 EST 2001

> Hi Jarl!  Sorry for taking a while to get back to this.
Hela Jeff, nah, dont mind, I'm slow too.. still got your BL compiling
error on hold.

> > But there's one issue that's big enough to discuss, the transparency of
> > the BL for passing DL -> PL communications. For the BL's sake in theory
> > there's no limitation of what can be passed on, I see none for the PL
> > because a NEW pl will be used, in paralel if needed.
> What do you mean by "a new PL"?
A new instance. same binairy, just a new copy.

> > The problem is with
> > the UI and DL which are not capable of handling new and threaded remote
> > input.
> >
> > When a DL has commited a network that is to be executed on multiple
> > machines, it will receive PUSHED responses.
> Can you give me an example of a pushed response?
Like an error message, a node has gone very wrong an want to output a
message about this event. Maybe the error is just temporary, and needs
to be updated, or removed. 

> > What do you think about this? And what about the amound of work it will
> > take to implement?
> I was thinking about a node that would work as an interactive tty/console,
> perhaps running Peep or bash.
> Are you talking about text that the UI and DL would not "expect", text that is
> only for the user and not to be passed on?

> Couldn't we put a "text viewer" in the pipeline of whatever application to do
> this?
The UI and DL need to be enhanced to accept messages from the BL\PL
backend, rather that just commit an execution network and exspect only
the end results. Maybe we could extend the bl->dl->ui communication, the
code that routes the results after a network has executed.


More information about the Pipet-Devel mailing list