<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="J.W. Bizzaro">
   <meta name="GENERATOR" content="Mozilla/4.6 [en] (X11; I; Linux 2.2.14-5.0 i586) [Netscape]">
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000">
<b><font size=+3><a href="#1">1 Overview</a></font></b>
<br><b><font size=+3><a href="#2">2 Goals</a></font></b>
<br><b><font size=+3><a href="#3">3 Design</a></font></b>
<br>&nbsp;
<br>&nbsp;
<h1>
<a NAME="1"></a>1 Overview</h1>
Piper is meant to be a visual shell, providing the user with a GUI and
a pipe mechanism to glue programs together. Piper exhibits several key
advantages over the old unix shell: distribution (as in distributed computing),
P2P capabilities (for resources discovery), non-linearity (scripts are
networks of pipes and not a sequences of pipes), artificial intelligence
aware, etc.
<p>Piper is a collaborative of separate layers, processes communicating
by CORBA. Instances of Piper communicate on P2P basis to each other.
<br>&nbsp;
<br>&nbsp;
<h1>
<a NAME="2"></a>2 Goals</h1>
This part tries to explain what the ends of Piper are. In other words,
it tries to answer the following questions: What is the intended usage?
What will piper be good for? What do we agree it can be bad at? What piper
capabilities are needed to get piper to be as useful and easy to use as
we expect it to become? What will the user see in terms of features? How
will the user(s) use it?
<br>&nbsp;
<h2>
2.1 Features</h2>

<h3>
2.1.1 Visual shell</h3>
System that let one graphically build programs by linking nodes.
<p>Piper will let one glue and reuse existing programs.
<p>For now refer to Jeff's presentation of <a href="#jeff-Aug2000">Aug
2000</a> and <a href="#jeff-Oct1999">Oct 1999</a>, to the <a href="#website-intro">Piper's
website introduction section</a> and to the
<br><a href="#command-compilation">command-compilation description</a>.
<br>&nbsp;
<h3>
2.1.2 Distribution</h3>
Programs can naturally be executed on different hosts.
<p>Explain how this will work for the user.
<p>compare to the use of rsh
<br>&nbsp;
<h3>
2.1.3 Peer-to-Peer</h3>
What is P2P used for?
<p>Resource discovery, instances/host coordination.
<p>Read the <a href="http://bioinformatics.org/pipermail/pipet-users/2000-November/001082.html">[Pipet Users]
Universal Description, Discovery, and Integration</a> thread in the mailing
list archives.
<br>&nbsp;
<h3>
2.1.4 Non-linearity</h3>
XXX: find better term?
<p>In a shell, pipes let one build sequences of commands, but not network
of commands without any difficulty (think of tee)
<p>XXX: what about flow control that seemed to exist in Loci?
<br>&nbsp;
<h3>
2.1.5 Artifical Intelligence Aware</h3>
Offers an AI toolbox of algorithms or other approach? Possible algorithms:
genetic programming, rule-based system, etc.
<p>What would they be used for? Find examples where AI algorithm/techniques
are useful in Piper. Do they need to be part of Piper?
<br>Can't these algorithm be nodes that would be linked in Piper to process
Piper internal information? Export internal information or
<br>implement reflexivity/introspection as in Narval?
<br>&nbsp;
<h2>
2.2 Working material</h2>
Here are pieces of information for those who would like to participate
in solving the big puzzle "what should piper do?".
<br>&nbsp;
<h3>
2.2.1 Website abstract</h3>
Piper is a peer-to-peer (P2P) distributed workflow system. It is an independent,
GNU-based project which brings the power and
<br>flexibility of the GNU/UNIX command-line interface (CLI) to the graphical
user interface (GUI) and Internet-distributed computing.
<p>Networks, programs, files, widgets, and so on, can be Internet-distributed
components represented in a GUI as the nodes of a flow
<br>chart. The user can join nodes via lines that depict links for data
flow, procedural steps, relationships, and so forth.
<br>&nbsp;
<br>&nbsp;
<h3>
<a NAME="command-compilation"></a>2.2.2 Overflow command-compilation</h3>
More info about "command compilation" and "what will using existing commands
and programs be like?"
<br><a href="http://www.bioinformatics.org/piper/documentation/command-compilation.html">http://www.bioinformatics.org/piper/documentation/command-compilation.html</a>.
<br>&nbsp;
<h3>
<a NAME="jeff-Aug2000"></a>2.2.3 Jeff's Aug 2000 presentation</h3>
Jeff put on-line the slides of a presentation he gave in august 2000. The
most interesting ones, relatively to Piper's use and features
<br>are:
<ul>
<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_02.html">Paradigm</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_03.html">Node
= location + I/O</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_04.html">Link
nodes' I/O</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_05.html">Nodes
have GUIs</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_06.html">Distributed:
local/remote nodes</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_07.html">View
= node GUIs instead of nodes network</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_08.html">Distribution/Collaboration</a></li>

<li>
<a href="http://www.bioinformatics.org/piper/documentation/bosc2000/slide_09.html">Reuse
existing prog, Scripting/Programming language</a></li>
</ul>

<h3>
<a NAME="jeff-Oct1999"></a>2.2.4 Jeff's Oct 1999 presentation</h3>
Describes the older <a href="http://www.bioinformatics.org/piper/documentation/scientific-apps.html">Loci
Project</a>.
<br>&nbsp;
<h3>
2.2.5 Website FOCUS &amp; GOAL section</h3>
Connect...
<ul>
<li>
Multiple objects</li>

<li>
With multiple links</li>

<li>
Of multiple types and protocols</li>

<li>
Between multiple computers</li>

<li>
Using multiple user interfaces</li>
</ul>

<h3>
<a NAME="website-intro"></a>2.2.6 Website INTRODUCTION section</h3>
Piper has two key components: an XML language for dynamically assembling
components across networks to construct new
<br>components and a graphical interface that makes this trivial for end
users. Piper plays an even larger role in the GUI and networks
<br>than pipe plays in the command line.
<p>...
<br>&nbsp;
<h4>
2.2.6.1 Piper is transparent component glue</h4>
Enter Piper. Piper, like pipe, moves the processes of gluing components
from C and and C++ code to the user level. Piper uses XML
<br>rather than C or C++ to describe how components are related to each
other. For example, if an email component talked to a spell
<br>checker component, this would be represented in an XML document as
a relationship between two components. When this document
<br>was loaded at runtime, Piper would dynamically create the relationship.
<p>Piper provides a simple graphical representation of component relationships
that users can easily manipulate. Rather than use the "|"
<br>symbol, Piper uses simple lines and arrows to connect different components
together and then allows users to change and add to
<br>these connections at will.
<p>Piper is significantly richer than the traditional world of pipes. The
goal of Piper is to be a complete XML component language that
<br>allows users to construct any program they need from a set of components
located anywhere on the Internet.This gives tremendous
<br>power to the user.
<p>Piper is multidimensional in that one component can have multiple connections
to other components, though this is not displayed
<br>above. When a set of Piper components is finished, users can create
a BlueBox user interface to the components. The resulting
<br>program will then be accessible from any platform that BlueBox has
been ported to.
<br>&nbsp;
<h4>
2.2.6.2 Piper Paradigm</h4>

<ul>
<li>
Everything is a component.</li>

<li>
Every component can accept (input) or produce (output) data, or do both.</li>

<li>
Components can be connected or "piped" according to their input and output
of data.</li>

<li>
All components have a network "location." Components can therefore be refered
to as "loci."</li>

<li>
Nodes are only represented locally, if possible.</li>
</ul>

<h4>
2.2.6.3 Benefits of Piper</h4>

<ul>
<li>
Easy to use graphical environment.</li>

<li>
A set of connected Piper components form a new Piper component.</li>

<li>
Programs can be dynamically reconstructed.</li>

<li>
Programs are transparent.</li>

<li>
Data and work flow can be easily managed throughout a network.</li>

<li>
Users can view current data and work flow throughout networks with windowlets.</li>

<li>
Gives users power.</li>
</ul>

<h4>
2.2.6.4 Narval</h4>
>From the list archives:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://bioinformatics.org/pipermail/pipet-users/2001-February/001247.html">Comparing
combination/flow/input-output mechanisms in current Piper and Narval</a>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://bioinformatics.org/pipermail/pipet-users/2000-October/001053.html">First
mention of Narval on Piper's list</a>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h2>
<a NAME="3"></a>3 Design</h2>
&nbsp;
<h4>
<u>3.1.1 UIL</u></h4>
UIL stands for User Interface Layer, and is the only layer that a user
will see. There can be more than one UIL for a Piper instance. The UIL
doesn't depend on a curtain type of display, it might be a text console,
Xwindows display, or anything else.
<h4>
3.1.1.1 creation of networks</h4>

<h4>
3.1.1.2 ...</h4>
&nbsp;
<h4>
<u>3.1.2 DL</u></h4>
The Definition Layer (DL) provides the glue for connecting two different
parts of Piper:
<p>- The Build-Time System. This part of Piper involves the user acting
through the user interface to create an interconnecting set of programs
to be executed.
<br>- The Run-Time System. This part of Piper is responsible for execution
of programs and piping information between programs.
<p>The DL rests firmly between the User Interface Layer (UIL) and the brokering
layer (BL) and mediates communication between these two sections of Piper.
In
<br>addition, the DL is responsible for storing XML describing the current
status of the userinterface, storing specialized XML descriptions of programs
and libraries,
<br>and communicating with remote Piper implementations.
<br>&nbsp;
<h4>
3.1.2.1 UIL-DL communications</h4>
Maintain communication with multiple user interfaces through a streaming
XML dialog communication protocol. This communication occurs though a local
<br>socket and allows user interfaces to be developed in any programming
language that provides support for sockets.
<h4>
3.1.2.2 Storage of XML data</h4>
Storing an XML representation of the user interface. This XML representation
models the connections between different nodes in the user interface and
the
<br>interrelationships between them. These XML representation will allow
users to save entire user interfaces or individual nodes, and will provide
the ability for
<br>recovery after crashes.
<h4>
3.1.2.3 Permanent storage</h4>
Maintaining a permanent storage location for specially designed nodes that
represent speci?c programs and libraries. The information for these nodes
will be
<br>stored as XML and be available directly available to the user interface
through the streaming XML dialog.
<h4>
3.1.2.4 XML transformation</h4>
Converting the XML representation generated by the build-time system into
an XML format that can be processed by the run-time system.
<h4>
3.1.2.5 Controlling the PL</h4>
Communication with the processing portion of the program by implementing
a CORBA client to a server in the brokering layer. This communication allows
<br>work ?ow diagrams to be passed to the processing layers for implementation,
and allows processes to be queried while running.
<h4>
3.1.2.6 Remote UIL</h4>
Communication with remote Piper programs as both a client and a server
using CORBA (through an idl that still has to be de?ned). This allows a
speci?c
<br>implementation of Piper to serve out a specialized node or set of nodes
to be utilized by other Piper implementations at remote locations. All
aspects of this
<br>remote communication will pass through the de?nition layer.
<h4>
3.1.2.7 main logging, glib based?</h4>
(http://developer.gnome.org/doc/API/glib/glib-message-logging.html)
<h4>
3.1.2.5 Communication Protocols</h4>
3.1.2.5.1 User Interface to Definition Layer
<p>Multiple user interfaces can communicate with the de?nition layer through
a CORBA interface de?ned in the IDL (interface de?nition language) ?le
uil2dl.idl.
<br>Further information on this communication is available in How To Write
a User Interface for Piper. Using CORBA for this communication protocol
allows user
<br>interfaces to be written in any language supporting CORBA language
bindings.
<p>3.1.2.5.2 Definition Layer to Processing Layer
<p>Communication between the de?nition and processing layers occurs using
a CORBA interface described in the interface de?nition language ?le vsh_dl2bl.idl.
<br>This communication occurs in three broad steps:
<p>1. The de?nition layer negotiates a connecting with the processing layer
and receives a unique id, the dlid for which to identify itself in future
communication.
<br>This connection is established by calling the following idl de?ned
function:
<p>interface Connection {
<br>processorS setup(in dlIdT dlid, in passwordT password,
<br>in connectionE connecttype) raises (IdInUse);
<br>};
<p>2. The de?nition layer uploads an XML document representing the programs
to be processed and the connections between them. This XML document will
then
<br>be parsed by the brokering layer and used to begin running the programs.
The brokering layer returns a URI id which the de?nition layer can then
use to further
<br>communicate with the brokering layer about the status of the processing.
The upload occurs through the following method:
<p>interface Representation {
<br>&nbsp;&nbsp;&nbsp; uriS upload(in string xmldocument, in dlIdT dlid,
<br>&nbsp;&nbsp;&nbsp; in passwordT password) raises (UriUndefined);
<br>};
<p>3. The de?nition layer then queries the brokering layer to determine
the status of different programs. When programs that return results are
?nished, the de?nition
<br>layer will then retrieve these results and return them to the user
interface to be displayed. Query and retrieval of processes are obtained
through the following:
<p>interface Obtain {
<br>&nbsp;&nbsp;&nbsp; statusS uriStatus(in uriS uri, in dlIdT dlid,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in passwordT password) raises
(UriNotFound);
<br>&nbsp;&nbsp;&nbsp; string uriInfo(in passwordT processid, in uriS uri)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; raises (InfoNotAvailable);
<br>};
<br>&nbsp;
<h4>
<u>3.1.3 BL</u></h4>
BL stands for Brokering Layer. For every instance of Piper there will be
only one BL running. The task of the BL are:
<br>&nbsp;
<h4>
3.1.3.1 brokering of DL-PL data flow</h4>
Data traffic between the DL and PL will be transported by the BL. Corba
is the technology used all over Piper, it's used to do DL-BL and BL-PL
transports. All DL-PL communication is XML formatted, and at runtime labeled
by BL with a URI identifier :
<br>&nbsp;&nbsp;&nbsp; /**
<br>&nbsp;&nbsp;&nbsp;&nbsp; * URI type, a locating id:
<br>&nbsp;&nbsp;&nbsp;&nbsp; * uriT is in a IP (Internet protocol) style
<br>&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uriT = 2.0.0
-> All subnets and nodes local in instance 2
<br>&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uriT = 74.35.0
-> All nodes in subnet 35 of instance 74.
<br>&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uriT = 1.2.3
-> Node 3 in subnet 2 of instance 1.
<br>&nbsp;&nbsp;&nbsp;&nbsp; */
<br>&nbsp;&nbsp;&nbsp; struct uriS {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dlIdT instanceID;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* Set by BL to DLid of DL that generated XML stream */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; blIdT subnetID;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* BL sets this */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; plIdT nodeID;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* ?PL sets this, ?BL parses XML */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; string description;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* ?ripped out XML, ?defined by DL */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; statusS status;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* BL handles this flag */
<br>&nbsp;&nbsp;&nbsp; };
<p>BL is capable of multiple instance communication, it uses a 'bookmarks'
list to locate other Piper instances. Remote Piper systems will be automatically
queried for available resources and nodes (?interfaces, ?public resources).
The BL will handshake to he BL of remote Piper instances that responded
to a query. All available nodes will be send in both ways during a BL handshake.
Available nodes include those nodes that are publicly available and those
in an area(*) that is active on the receiving BL. An area in a set of nodes
that all share the same area id. Those nodes can spread across Piper instances.
<br>&nbsp;
<h4>
3.1.3.2 communication between instances of Piper</h4>
BL - BL communications are not defined yet. A good candidate CorbaSec (http://cadse.cs.fiu.edu/corba/corbasec/faq/single-page/CORBASEC-FAQ.html).
But maybe it will turn out this implementation is too heavy for the modal
internet connection.
<p>TODO: Write idl \ communication API
<h4>
3.1.3.3 Security system</h4>
The BL should have a system that handles area's. An area is created by
the BL when a DL requests one. The area is given a unique number, the areaId.
The id and the password supplied by the DL at creation time will be needed
for access to that area. On the Piper instance where the area is created
(?area creation host), and at remote Piper's that host the area (?area
hosts). Closing down the area on a ?area host is not possible. Putting
tight quota's on an area on a ?area host is possible. The ?area creation
host can shut down the area, but by doing so, all parts of the area located
on remote systems will become separate area's, with new unique id's. ?area
hosts become ?are creation hosts once this happens.
<br>The implementation of the security system should be based on ?akenti
or ?sesame. Internally the BL should user the real node addressing, outside
the core, at the plugin- and DL-interfaces level, a different node id system
will block the interface to overrule the security.
<h4>
3.1.3.4 resource management</h4>
The BL policy is to obey resource quota's. Quota's can be set on ?networks
executed at once, ?cpu load, ?disk usage, ?ram usage, ? ... The BL does
active optimization of network execution. This is done by feeding historic
data about network execution times to an GP engine. Once the GP engine
starts to return hits with very high fitness, the BL will listen to the
GP engine instead of the DL. The GP expectations will overrule one node
parameter given by the DL. This is the requested location where the node
should be executed. The GP engine will might operate exploration, so produce
random results that indicate high finesses.
<h4>
3.1.3.5 ...</h4>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h4>
<u>3.1.4 PL</u></h4>
PL stand for Processing Layer. A PL exists only during the execution of
a network. When a new network needs to be executed, a new PL is spawn for
that network. After the network is finished that PL quits running to. It
should do:
<h4>
3.1.4.1 execute networks</h4>

<h4>
3.1.4.2 handle legacy issues</h4>

<h4>
3.1.4.3 ...</h4>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h4>
<u>3.1.5 GPL</u></h4>
GPL stands for Genetic Programming Layer. There is only one GPL for every
PIper instance. It's task are to:
<h4>
3.1.5.1 support DL, BL and PL with GP facilities</h4>

<h4>
3.1.5.2 use spare cpu cycles to process historic information for future
optimizing</h4>

<h4>
3.1.5.3 ...</h4>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
<u>3.1.6 All Layers together</u></h3>
UIL &lt;--> uil2dl &lt;--> DL &lt;--> dl2bl &lt;--> BL &lt;--> bl2pl &lt;-->
PL&nbsp;&nbsp;&nbsp;&nbsp; &lt;==>&nbsp;&nbsp;&nbsp; <i><u>Executed Nodes
and Applications</u></i>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
dl2ail&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bl2ail&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
pl2ail
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------ AIL -------------+
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
3.2 Interfaces of Layers</h3>
All layers communicate by Corba to each other. These interface have fixed
IDL definitions, and some additional properties like 1-1 or 1-N relationships,
security issues.
<br>&nbsp;
<h4>
<u>3.2.1 uil2dl</u></h4>
The UIL and DL have a 1-1 relation.
<p>TODO: Add uil2dl API
<br>&nbsp;
<h4>
<u>3.2.2 dl2bl</u></h4>
The DL and BL have a N-1 relation
<p><i>See ./piper/idl/DL2BL.idl for complete API</i>
<br>&nbsp;
<h4>
<u>3.2.3 dl2ail</u></h4>
The DL and AIL have a N-1 relation.
<p>TODO: Specify dl2ail
<h4>
<u>3.2.4 bl2pl</u></h4>
The BL and PL have a 1-N relation.
<p><i>See ./piper/idl/BL2PL.idl for complete API</i>
<h4>
<u>3.2.5 bl2ail</u></h4>
The BL and AIL have a 1-1 relation.
<p>TODO: Specify bl2ail
<br>&nbsp;
<h4>
<u>3.2.6 pl2ail</u></h4>
The PL and AIL have a N-1 relation.
<p>TODO: Specify pl2ail
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
3.3 Dependencies</h3>
These 3th party libraries are needed for Piper:
<p>- glib
<br>- gdk
<br>- gtk+
<br>- omniOrb
<br>- ...
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
</body>
</html>