The Loci/Piper Project

ABSTRACT

INTRODUCTION

FOCUS & GOALS

DESIGN

BACKGROUND

CONTRIBUTORS

MAILING LISTS

DOCUMENTATION

SCREENSHOTS

DOWNLOAD

INTRODUCTION

(Thanks to dLoo for this introduction.)
 
Piper has two key components: an XML language for dynamically assembling components across networks to construct new components and a graphical interface that makes this trivial for end users. Piper plays an even larger role in the GUI and networks than pipe plays in the command line.

 

The Command Line

The UNIX command line is the heart of UNIX tradition. It provides access to a set of simple tools that do one thing well.

In a typical command line session, a user might list files: 

Count the lines in a document: 

And list all of the processes in their user space: 

The UNIX philosophy of providing a large base of simple tools creates a simple language in which users can manipulate files and directories.
 

Merging 'ls' and 'sort'

Without pipes, the UNIX language would consist of nothing more than one word grunts. Users, for example, would be able to list files with 'ls' and sort items in a file with 'sort,' but they would not be able to sort the output of a listing of files. Only programmers, with an intimate knowledge of C, could to link the two. 

Creating a link between two UNIX utilities, something called a named pipe, would require the following code:
 
/* set the umask explicitly, you don't know where it's been */
umask(0); 
if (mknod("test_fifo", 
                    S_IFIFO | S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP, 0))
{ 
      perror("mknod"); 
      exit(1); 

                                                    Ref: Unix Programming FAQ v. 1.34, section 2.10.2 

Even worse, in a world without pipes, the above solution would connect 'ls' and 'sort' in a manner that was neither general nor flexible. In this way, it would encourage users to create large, single purpose, monolithic programs rather than the simple utilities that are the spirit of UNIX. 
 

Pipe is transparent I/O glue

Enter pipe. The pipe utility, "|", is one of the most important utilities in the UNIX world of the command line. With pipe, users can glue the I/O of simple utilities together. 

Users can list processes: 

Sort a list of processes: 

Uniquely sort a list of processes: 

Count the number of uniquely, sorted processes: 

As can be seen above, "|" transformed the UNIX from a set of single word utilities to a rich language that users can use in an infinite variety of ways. By moving the process of gluing utilities together from the programmer level to the user level, "|" gave the command line the power it has today. 
 

Benefits of pipe

  • Fits naturally in the command line interface 
  • Requires no knowledge of programming 
  • Easy to Use 
  • Transfers power from programmers to users 

 

The GUI

Today, most users have left the command line to work in graphical users interfaces. This provides an easy to use graphical environment for users to work in, of which both KDE and GNOME are examples. 

Users can access the file system:

Run spreadsheets:

And more:

Desktop environments, like KDE and GNOME, provide a uniform view of the file system and access easily used programs ranging from calculators to spreadsheets. These programs are build by assembling components in C, C++, and other programming languages. 

Although it is easy for programmers to connect components together in these environments, it is not easy for users. Doing so requires code like the following: 
 
#include <orb/orbit.h>
/* here, code to access the interface */ 
int main (int argc, char *argv) 
{
     CORBA_Object obj; 
     CORBA_Environment ev; 
     CORBA_ORB orb; 

     CORBA_exception_init (&ev);
     orb = CORBA_ORB_init (&ev);

     if (ev->_major != CORBA_NO_EXCEPTION) {
        fprintf (stderr, 
                        "Error: unable to initialise the ORB: %s\n",
                         CORBA_exception_id (&ev)); 
      CORBA_exception_free (&ev);
      exit (1); } 

                                                             GNOME Bonobo Manual, Section 2.4 

or the following:
 
bool BarObject::process(const QCString &fun, const QByteArray &data, 
                                             QCString &replyType, QByteArray &replyData) 
{
     if (fun == "doIt(int)") { 
     QDataStream arg(data, IO_ReadOnly);
     int i; // parameter 
     arg >> i; 
     QString result = self->doIt (i); 
     QDataStream reply(replyData, IO_WriteOnly);
     reply << result; replyType = "QString"; 
     return true;
   } else { 
     qDebug("unknown function call to BarObject::process()"); 
     return false; 
   } 
}
KDE DCOP HOWTO, Section 2.2.3 

Few users know CORBA or DCOP, so this puts a tremendous burden on them if they want to connect components in new and novel ways.
 

Piper is transparent component glue

Enter Piper. Piper, like pipe, moves the processes of gluing components from C and and C++ code to the user level. Piper uses XML rather than C or C++ to describe how components are related to each other. For example, if an email component talked to a spell checker component, this would be represented in an XML document as a relationship between two components. When this document was loaded at runtime, Piper would dynamically create the relationship. 

Piper provides a simple graphical representation of component relationships that users can easily manipulate. Rather than use the "|" symbol, Piper uses simple lines and arrows to connect different components together and then allows users to change and add to these connections at will. 

Piper is significantly richer than the traditional world of pipes. The goal of Piper is to be a complete XML component language that allows users to construct any program they need from a set of components located anywhere on the Internet.This gives tremendous power to the user. 

The work on Piper has just begun. Right now, Piper allows users to view the components that programs are built out of:

Create new programs by connecting new components


 

And view the data flowing over individual components 
 

Piper is multidimensional in that one component can have multiple connections to other components, though this is not displayed above. When a set of Piper components is finished, users can create a BlueBox user interface to the components. The resulting program will then be accessible from any platform that BlueBox has been ported to. 
 

Piper Paradigm

  1. Everything is a component. 
  2. Every component can accept (input) or produce (output) data, or do both. 
  3. Components can be connected or "piped" according to their input and output of data. 
  4. All components have a network "location." Components can therefore be refered to as "loci."
  5. Nodes are only represented locally, if possible. 

Benefits of Piper

  • Easy to use graphical environment. 
  • A set of connected Piper components form a new Piper component.
  • Programs can be dynamically reconstructed.
  • Programs are transparent.
  • Data and work flow can be easily managed throughout a network.
  • Users can view current data and work flow throughout networks with windowlets.
  • Gives users power.