[Pipet Users] Re: LWN referenced Piper today

[J.W. Bizzaro]

Hi Michael!  Thanks for writing.  We apologize for the late reply;
several of us are in Denmark for a meeting right now.

I'm not the networking guy in the project, Jarl is, so I'll leave some
of your points for him to answer.

> A quote from one posting[1] suggests you have been considering using XML to
> define the GUI interface layout.  I also gather from the discussion on the
> design of the project that the glue to hold the architecture together is
> CORBA and a primary design goal is to manage workflows.

Both true.

> Managing workflows is a very general problem which also applies to almost any
> business activity. This generality is a good thing and makes the technology a
> potential foundation for many projects.  I'm interested in applying workflow
> sotware to business management activities.  This generality also means that
> many other people are attacking the same problem domain and as a result we
> have many projects solving the same problem, with slightly different
> approaches and architectures.  This presents a problem when trying to select
> the appropriate solution and it also makes it very difficult for potential
> peers to collaborate if they each choose different base technologies.

Yes.  Piper is perhaps unique in the field for being rather
general-pupose -- not requiring new or specific programs -- among other
things.  Bur standards are indeed difficult to create and impossible to
control or inforce.

> There is a second problem.  Piper is already the result of several projects
> merging, so, as I am sure you are aware, a common problem facing projects
> like Piper is that the chances of long term survival are determined by both
> the goodness of the design  and the momentum behind the project.  Projects
> with large followings have a higher probability of success, given equally
> good architectures.

I'm not sure this is a problem.  As someone commented to us, the fact
that we are merging several smaller projects ensures modularity.  Any
part of Piper will be swappable for anything else.  We actually consider
Piper to be a reference for the PiperNet standard, allowing other
variations on the Piper theme to be made.

> Assuming my summary of Piper is correct I would like to suggest that the
> Piper project team might benefit from some of the technology that is
> currently under development on the Zope CMF project.  I didn't see your email
> address on the zope-cmf at zope.org mailing list, so I assume you are not
> following that project closely.  The CMF architecture is summarized on a Wiki
> page[2].   It discuses the plans to convert CMF to use the new Zope component
> model.  With the recent addition of Workflows to the Zope CMF the amount of
> overlap between the Zope project and Piper has become quite significant.

We are well aware of Zope, and a few years back we considered using Zope
to make Piper (when it was Loci).  I think we felt that Zope did more
than what we needed and that it would be a large dependency that not
everyone would have by default.

> The strength of Piper, and a weakness of Zope, is the interactive GUI.  The
> Zope project has concentrated on the server side.  The only GUI for Zope uses
> web pages.  This works, but it is not appropriate in some situations.
> Applications need a custom GUI for daily interactive use or when
> visualization requires an interface design that isn't readily represented as
> a web page.  Consequently, visualizing and designing Zope workflows is very
> awkward using the web based interface.

I designed the Piper desktop, and I agree with your assessment of Web
interfaces.  I usually argue that the Web was designed to be a document
publication system, not an application GUI builder.  I find "scroll up
and down" and "flip back and forward" to be inhibitive to any real
"work".

> What I envision is a grafting of the
> Piper interface onto the Zope CMF workflow architecture.
> 
> As you probably know the Zope technology includes many conduits for passing
> information into the Zope object store. In addition to HTTP the Zope server
> can be manipulated through WebDav, and XML-RPC.  The XML-RPC technology is a
> lightweight replacement for CORBA.  Shifting the Piper architecture from
> CORBA based to a XML-RPC looks interesting, but I don't think it would not be
> the appropriate approach.  There are two problems.  The XML-RPC interface has
> bandwidth limitations caused by the use of HTTP as the transport protocol.
> Each transaction requires reestablishing connections.  This isn't appropriate
> for a peer to peer networking arrangement.

We tried an XML-RPC-like object model at the very beginning.  We found
it to be VERY SLOW, so we switched to CORBA.

So, why does Zope use XML-RPC instead of something like SOAP?

> A more appropriate solution for building peer to peer interfaces between Zope
> servers would be to add yet another conduit type to Zope.  This isn't hard
> because Zope was designed to support multiple connection types.  Adding the
> IETF BEEP framework[3] to Zope is how I envision the architecture evolving.
> The BEEP framework was specifically created to build peer to peer protocols.
> The Zope workflow interface would be exposed on top of the BEEP framework.
> And the Piper user interface would control the Zope workflow interfaces by
> connecting to the Zope servers over the BEEP based conduits.

It may be possible to do this, since there are some things left
unresolved in the Piper Broker.  However, I'll leave it up to Jarl to
decide if this would mean too much of a change.

As I mentioned before, swapping out the Piper Broker for Zope is a
possibility.

> Tthe use of XML to define the GUI is also a good idea and can be done in the
> libglade user interface.  The Glade interface builder saves the GUI design as
> .glade files. These files are then read into an application by using the
> libglade module[4] in Python.  The application then associates callbacks
> names defined by Glade with the appropriate functions or methods in Python.
> This works very nicely for building user interfaces, but the Glade
> application sits separate from the application that is built with Glade.

Yes, we did get the idea from Glade.  We also want to define parameters
using something like the HTML "form" tags.  We could use Glade to build
some interfaces, but it may not be required.  We could also use Bonobo.

> I
> would like to see the Glade application rewritten as a Python module. This
> would allow applications to embed a GUI builder into the application.  This
> way the GUI builder could be aware of the application functions and present
> them as options to be automatically associated with the callbacks.

That sounds like a good idea :-)  Actually, when I asked, they said they
had no intention to support Python in Glade :-(

> I know this would be another big change for the Piper project participants
> and some code would have to be rewritten, but I suspect that the added
> momentum behind Zope and the CMF will get the Piper project back to parity
> with the current state of the project in a couple months.  At that point the
> growth of both Piper and Zope-CMF will be greater than if the projects
> continue as serparate activities.

That's the argument I always make for collaborations, how Piper was
formed actually ;-)

I think there are some interesting possibilities.  I will talk about
this with the others here in Copenhagen tonight.

Cheers.
Jeff