[Pipet Devel] Re: GNU Piper

[J.W. Bizzaro]

Nile Geisinger wrote:
> 
> We've been very
> excited about this and I can tell from your email
> you're excited about it as well. The idea of
> graphically assembling these connections is a
> remarkably beautiful addition, though, I must say.

Well, once you realize how pervasive tree structures and flow charts are in
computing, you start seeing how all sorts of stuff can be done with a single
program that lets you graphically manipulate the structures.  We've picked up
on all sorts of jewels over the past couple years, for example...

  How about database management and mining:
  http://www.spss.com/clementine/newshow/sld001.htm
  http://www.cerebellumsoft.com/product/designer.html

  Data visualization:
  http://www.avs.com/products/expdev/netedit.htm
  http://www.research.ibm.com/dx/csfig21s.gif

  CLI -> GUI conversion and GUI construction:
  http://www.cnb.uam.es/~bioinfo/Colimate/Extra_Docs/snapshot.html
  http://www.geocities.com/SiliconValley/Bay/5371/gchip.html

  Or how about using these structures to describe SVG/vector and OpenGL
graphics:
  http://www.levien.com/svg/
  http://asterix.jci.tju.edu/weber/model.html

But these are special-purpose systems.  No one, to my knowledge, has made a
general-purpose system that is basically a framework for doing all this neat
stuff...until now :-)  Yes, we're excited!

> I've spent some time studying your project since
> reading the email. What I've found fascinating is
> that, even though we were working from two different
> visions, we ended up with very similar results.

Indeed.  I'm fascinated by how we both have birds for mascots ;-)

> Our goal was to bring the network effects to
> programming that the web brought to publishing. In
> pursuit of this goal, we created a simple,
> cross-platform, HTMLish, language that ordinary people
> could use to build programs. It allows them to:
> 
> 1) Describe interfaces in XML (just as one does in
> HTML)
> 2) Link to interfaces and components (again like HTML)
> 3) Describe component interactions with each other
> (not like HTML but still simple). We call this
> linking, you call this piping.

You'd have fun digging through our e-mail archive and finding how we developed
a similar plan.

BTW, we call it too many different things.  Agreeing on names, when we're
working between several different countries, has been difficult.  But we all
thought "Piper" was a cool project name :-)

> In this way, the whole program is described in a set
> of XML pages. This allows sites to publish XML pages
> that linked to XML pages on other sites, create XML
> links that link two component together, dynamically
> generate programs in XML, etc.
> 
> In short, just like the web.

Exactly like Piper :-)  We even discussed plans for a directory service so
that users can locate nodes/applications across the Internet.  We thought
about a Napster-like (centralized) system, but our plan is now for something
like Gnutella (distributed).

> Piper's goal, to my understanding, is to bring UNIX
> piping up to the GUI level.

You may have noticed that we plan on having MULTIPLE user interfaces.  The
default is, in fact, console-based since it allows installation and execution
without a desktop running (i.e., on a server).

My personal part in this project (besides being a coordinator) is to integrate
Piper with the desktop.  I guess I'm the GUI guy on the team.

Also, Piper is meant to add an extra dimension to I/O redirection.  The UNIX
shell lets you connect output to input between 2 programs sharing the same
protocol, but it's not very good at dealing with multiple I/O's and multiple
protocols between multiple programs.  Typically, in such a complex situation
in UNIX, you write a shell script.  This means typing in a text editor.  But
the Piper approach, regardless of user interface, is to treat a network of
applications like a file system (Ah-ha! Another tree!) or even the web.  So,
the user browses around the network hierarchy (in the Build-Time Subsystem)
telling Piper essentially "Connect this" and "Disconnect that".

> It's primary focus is with
> piping data and has built a great graphical
> environment/SDK around this. Piper has also seperated
> out "Interface and how the Interface links to
> components" with "How components link to each other".
> A nice design choice that is missing from our model.

Thanks :-)

> What our different visions mean in practice is that in
> terms of priorities, Piper is heavily focused on 3.,
> while we are heavily focused on 1 and 2, with 3
> planned for a later release. All three components are
> important in both of our models. The metaphors we have
> been  working from have just put a different emphasis
> on the problems we try to solve first.

Piper is certainly interested in 1 and 2, with 3 planned FIRST.  As you say,
we're working at this from different ends.

> As you noted in your mailing list,

Are you on the list?

> BlueBox could serve
> as your UI. In the same way, if we used your piping
> work, we would not have to do component assemblage at
> all in our language. And we would have a nice
> seperation between interface and component
> interactions. Piper and BlueBox could work very well
> together.

Piper is actually the merger of 3 other projects that complement each other:
Loci, GMS, and Overflow.  So, we know the advantage of joining forces :-)  It
is rare too, these days, when it seems everyone in Open Source development is
making "Yet Another E-Mail Client" or "Yet Another Clone of a M$ Product". 
Have you noticed how many gnotepads there are?  Three share the same name but
not any code ;-)

> To make sure that we are on the same page, here is how
> I envision user experience with Piper, BlueBox, and
> DSML directory services:
> 
> 1) A user opens a file browser (whether Nautilus or
> Konqueror) and browses to whatever directory of files,
> programs, or piper components that they want. These
> files, programs, etc. can be located anywhere on the
> network (a directory server has some duplicate work
> with Piper here). If there are piper components in a
> directory then the user can link them together using
> piper tools built into the browser(i.e., it has the a
> piper toolbar or the right click mouse option).

Yeah, I guess you're talking about having the native file manager select the
raw (un-piped) components, and then the user can drag them into Piper somehow
to work with them.  Right now, we have the workspace but haven't added any
interaction with a file manager.  It is planned though.

> 2) Files when clicked on launch the program they are
> associated with.

...even withing the Piper workspace.  We will be using both windowlets (stay
attached to the icon) and full-fledged windows.

> 3) Programs have three different ways of being
> selected. They can be doubleclicked or right clicked
> with "Edit Interface" or "Edit components" selected.
> 
>         A) If double clicked program launches

...or opens window/let.  For some programs, that may be the same thing.

>         B) If Edit interface Glade (or the like) launches to
> edit BlueBox interface. In this way a user can change
> the interface at runtime.

Yes.  For low-level changes (intra-widget changes), we were also planning on
using Glade.   What a coincidence :-)

>         C) If Edit components, a seperate piper window
> launches with all of the programs components that the
> user can connect and change with piper. In this way a
> user can change the program itself at runtime.

Yes.  For rearrangement of widgets (inter-widget changes), we were going to
use the hierarchy or arrangement of nodes in the network to determine that. 
(I really need to write something about that, because most people don't know
what I mean and how it can be implemented.)  

> In this view of the world, Piper would be an integral
> part of the KDE/GNOME environment. As would BlueBox.
> As would the DSML directory server. With XML tying us
> all together.

They certainly could be integral.  It will just take some time for people to
see the value in them.

Also, it is a good idea to include KDE our plans (although I am a
Gnome/Gtk/GNU advocate), because any exclusion will cause that camp to
re-invent our efforts, either intentionally or not.

> There are obviously different questions to be answered
> about how the projects would interface and there are
> several factors involved that we have to carefully
> consider over here.

As long as we don't have to change the name again.  Count so far, including
projects that merged: Tulip, Loci, vflow, Overflow, gMessaging/GMS, VSh, and
Piper :-)

> However, there is the potential
> for us each to save the other a tremendous amount of
> work, not to mention the excitement of working on a
> similar goal. Let me talk to the other team members
> here. If we do decide to collaborate, we will probably
> want to provide you and other developers with equity
> in our company as a means of supporting your efforts,

Well, we look forward to hearing back from you.

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+