[Pipet Devel] BL PL design documentation

[Jarl van Katwijk]

> You only mention briefly the idea of the centralized name-server that
> Piper has to connect with to know about other Piper instances on the net.
> >From your listing of tasks, it appears as if you would like the BL to be
> the place where all of this communication occurs, and hence the place
> where the name-server stuff would be implemented.

This central coordination database will a separate application outside the
scope
of the 4 Layers of Piper (opposing the 666 Layers of Hell :) ).
It will register all BL together with their 'allowed users list' so that a
BL can
locate other BL's where it can distribute nodes to.

>
>
> You only talk about KQML remote communication, so I'm not sure exactly
> how this implementation will work. What are your thoughts on this?

In order to have BL's communicate across a distributed network, KQML is
the API that is specialized for this job. I cant go into details for now
simply because
I'm not really familiar with the KQML api yet. But I've been reading about
this
and everybody that has something intelligent to say about handling
communications
within a distributed framework say kqml is the way to go. Ofcourse it will
be
KQML over Corba. I'll try to integrate settled KQML technology into the BL
like
http://www.forwiss.uni-erlangen.de/~msnutt/kapi/kapi-2.7d.tgz. Also see:
http://www.cs.umbc.edu/kqml/kqmlspec/spec.html

>
> I would like to argue that we give the DL the responsibility of finding
> other available Piper instances, and then returning this info to the BL
> (we could design an addition to the dl2bl.idl interface to handle the BL
> requesting the info from the DL). I think this is good for a couple of
> reasons:
>
> 1. This way we can write and prototype the whole thing in python, which,
> IMHO, is very nice for designing CORBA stuff in. I'm quite worried about
> fighting with C++ memory issues, especially for a long running
> name-server.

Right.

>
> 2. I'm a little worried about the BL becoming huge and unweildy if it
> gets assigned a ton of tasks (it already has communicating with the DL
> and BBL, doing node splitting, GA stuff, using KQML to communicate with
> remote BLs).

Getting some work out of my hand? Sure! :)

>
> 3. I think this is a nice separation between "high-level" remote
> communication (ie. finding out what other Piper programs are out there)
> versus "low-level" remote communication (ie. querying for getOutput()
> requests).

ok, the DL will handle Piper instance localisation.. maybe you can also
think
about this cantral database that will supply this info IYKWIM?

>
> Nah, you can give my +1 to keeping the "family names." Not only is it
> more descriptive of what is going on, it is also a heck of a lot more
> interesting, even if it may be a bit corny :-). Man, if we can't be a
> little corny, what else do we have left?
>

We'll only have 2 pices of code that bare the name BL: THE BL and a PL
wrapper
that people call the BabyBL. This name is ok to me, but much clearer would
be to
call it "The PL plugin for the BL". I think you can see why. It's just a
diff. way of
looking at the situation..

bye,
jarl