[Pipet Devel] ideas for a smaller piper core

Jarl van Katwijk jarl at xs4all.nl
Tue May 29 17:50:47 EDT 2001

> > About the modulairity: to me Piper is just a set of specifications
> > implemented by packages of software labeled 'Piper compliant' by us.
> separate packaging of the UIL+DL+BL+PL will not
> prevent us from calling them a standard/reference, providing we specify which
> components should be used for a standard/reference.
right. Maybe I'm missing the point here: are you looking for an easy way
to install Piper? Practically bundling all needed components into on
package is the most simple installation. 

> What is my motivation for wanting separate packages?  What would the standard
> gain by it?  As you said, separate packaging will facilitate a quick change in
> the standard, if needed.
I'm not sure I got this one: are you saying separate packages allow a
more flexible upgrade procedure?
Also I'm not saying we should use separate packages for the distribution
of Piper: use a complete tarball containing the best implementations  we
got so for. Untill we got a nice installation procedure based on a fully
documented Piper environment ;-)
In short: supply as much functionality in one package untill we're no
longer in alpha state. Something that could be very close to what you
actaully want and did 1st post I guess. You seem to be lookin for the
quickest way to get a simple working piece of code that's working?

> What would users gain by it?  As I mentioned before, it would allow high-end
> users (those wanting to incorporate Piper into their systems, like Narval or
> BlueBox) to quickly swap components.  Additionally, low-end users won't have
> to upgrade the whole Piper system when there is a change in only one
> component.
This could be, and to my view should be, done in the configure script.
Maybe have a try Jeff at chancing that script. It's very confusing
systax at 1st, but you manage ;)

There's is another PRO for an installation system that's capable of
installing separate packages Jeff did not mention. An Piper that always
installs the 4 default layers will overwrite or de-configure
non-official parts during an upgrade. 

So lets package 4 default layers into Piper, and make (some?) of them
optional to install.

More information about the Pipet-Devel mailing list