Re: UPS Package

Philippe Jausions wrote: >IMHO, most of those patterns wouldn't be part of that PEAR >"Service_Shipping" package(s). Since this is PEAR (with all the CS) "we" >can and will define the common minimal API to all shippers. This should >take care of the Proxy patterm. I see it useful to bridge the gap >between PEAR and non-PEAR classes, but it is a specific of an >application, hence not a PEAR problem. If someone wants to use a >third-party class, they can either ask the author to include it in PEAR >or write a proxy to it for their own use. I don't see PEAR accepting >proxy packages... If only one developer was to develop each and every Shipping packages, your solution would probably work but I doubt this is feasible unless you find someone who has an undecent amount of free time available :) I think that, at this point, we still don't have much visibility of the different API proposed by the Shippers. IMO, using a proxy instead of enforcing the same API for all Shipping packages would allow developers to work independently, while being aware of what the requirements are in order for the package to be compatible with the main Services_Shipping package. In this sense, the Proxy might only be a subset of all the functionalities provided by the Shipper package. Still, if someone is only interested in the UPS package, they will be able to use it directly instead of using the main Services_Shipping package. This way, they will have access to a lower level API while the Proxy object provides a higher-level API. Something like HTTP_Request and HTTP_Client... But more flexible because it is also using the Strategy pattern (which you ignored in your comments ?). >It appears to me that all this would apply more to a shipper-selector >type-of package. Something like "Find the cheapest shipper for a 2-day >delivery". This would certainly be useful for a automated warehouse >application, but maybe not as a starting point for this PEAR shipping >package... This could be one of the functionalities of Services_Shipping. Another functionality could be getRates(array(Shippers), array(Parameters))... The Services_Shipping package could also have a factory method in order to easily instanciate a Shipper object. Something like DB::connect(). >As someone said before, each shipper "driver" could have a whole lot >more than the common API to be used alone. That's exactly the idea. >As far as the cached shipper table, are you refering to shipping cost or >list shippers. I don't think rates should be cached, too complicated and >rates change all the time. This would be rewriting the shipper web >service itself as PEAR ones... I don't see the advantage. IMHO, what is >being attempted is to write web service *client" packages. That's of course not something I would do in the first place but caching a Shipper's rates, in a database for example, would speed up the process so that is something people might be interested in, in the future. FYI, the CPAN Shipping package provides this functionality out of the box. The idea is not to implement it ourselves, the idea is to give developers the freedom to do one for themselves if they want to. That's also where the Strategy pattern comes to mind. Here is a proposed package organisation: * Package Services_Shipping Services/Shipping.php Services/Shipping/Shipper.php --> An abstract interface for Proxy Services/Shipping/Parcel.php * Package Services_Shipping_UPS Services/Shipping/Shipper/UPS.php Services/Shipping/Shipper/UPSProxy.php --> Proxy implementation using the context of Services_Shipping Services/Shipping/Shipper/UPS/Rates.php Services/Shipping/Shipper/UPS/Tracking.php Services/Shipping/Shipper/UPS/... <-- Whatever services are offered A shipper collection could be managed in Services_Shipping through a registry object (see the Registry pattern) Services_Shipping_ShipperRegistry. I hope this makes more sense :) Please note that patterns are here to make your life easier, especially in cases like this one, not to make it more complicated. Bertrand Mansion Mamasam