[Pipet Devel] running the latest source

[jarl van katwijk]

> Woo-Hoo!  I got the very latest Overflow and Piper+BL compiled and running
> (RedHat 6.2 for Intel).  No problems yet :-)

Even on Redhat ;)

>
>
> Jarl asked us to test the BL for him.  Jarl, could you write a tutorial on a
> simple test of the BL using the GMS GUI?
>

My plans for the BL_admin are that it should be disposed of as soon as possible.
But for now you can do some simple testing with it; simple because using some
features will let the tool crash.

Firstly you need to remember the design of the BL:
A.- Based on a signle type of node that has a name based on the situation, it can
be a :
    Aa.- Sensor when it's routing data from the environment into the BL. In Piper
there will be 2 sensors: from the DL and from the PL. The rest are just the old
GMS plugins, that gather data from syslogd, localhost and irc (not compiled by
default). Sensors are linked to the Piperline by default and can't be given other
links.
    Ab.- Piperline. There is always just one pipeline for one instance of the BL,
where things such as authorisation and scheduling will be handled. You can't play
with this one.
    Ac.- Collectors are nodes that have a 1-on-1 relation to sensors, for every
sensor there's one collector. Collectors are the 'instance of a sensor that has
passed the pipeline's criteria' so to say. Collector's differ from sensons in
that they can be given multiple relations to other nodes (Filters and Visuals)
    Ad.- Visuals are the nodes that output datastreams to the environment, the
DL or PL in the Piper framework. The old GMS plugins can also output to irc,
scrath panel, alarm applet, speechtsynthesis, etc.
    Ae.- Filters are nodes that just process data, they're positioned between the
collectors and visuals. They wont be used in Piper so you wont find them in the
BL_admin.

Crashing the BL_admin is too easy:
1.- crashing when you select a Visual or a Sensor. This is because after a
selection of such a plugin should display the configuration it in the window
below the component, which makes use of a feature of gtk that wouldn't work after
the C -> C++ port. I let this be to work on the connections between the DL and
PL.
2. - Also the output windows of the visuals are empty (the empty tabs), because
these make use of the same gtk stuff as 1.

Testing is a bit harder ;)
1. Viewing the 4th tab, which shows all loaded & initialized plugins
2. Using the 3th tab (Collectors), which can be given relations to visuals.
Select on of the collectors, 'Add' new relations.

The problem with testing is that the only 'usefull' sensor (input data stream) is
the syslogd monitor plugin, and that this one needs to have root permissions. You
can give the irc sensor a try, but this one need to be configured at source level
because the configuration panels dont work yet.

So the real testing is yet to come when it's possible to upload the networks from
the UI to the PL and monitor it by using the BL_admin.

bye,
jarl