Re: UPS Package

Greg Beaver wrote:

I would like to see Services_Shipping, and then subpackages Services_Shipping_UPS, Services_Shipping_Fedex. Each should have their own release cycle.

Yes, because each subPackage depends on each furnisher.

Either that or each should have the same API and just be separate. After all do we really need a class to do: <?php $a = Services_Shipping('ups'); ?> when we can just do: <?php $a = new Services_Shipping_UPS; ?> Now, if Services_Shipping contains methods for aggregating data (for instance, a cost comparison from many shippers), then it would be useful.

More, should Services_Shipping give a template abstract class to generalize the interface to concrete (UPS, Fedex...) The aim is to have a real flexibility against parcel delivery furnisher: - it depends on commercial politic not under the control of the developper - this politic is often to use say UPS in america and say Chronopost in Africa so your script must cope with the both - it can be included in some general e-commerce portal, where it's the end implementation who determines which parcel service is used Anyway, this general class could only define the basic data and action of parcel services. (what correspond to a first simple release)

In addition, you can use the new package.xml format as soon as I finish PEAR 1.4.0 to set up default installs and other perks. Greg As I'm to you, can you check my last post on "Rethink CS for require_once" ?

Bye. -- bertrand Gugger (toggg)