<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 16, 2013 at 11:50 PM, Stefan Hornburg (Racke) <span dir="ltr"><<a href="mailto:racke@linuxia.de" target="_blank">racke@linuxia.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/16/2013 08:43 PM, William Carr wrote:<br>
><br>
> On Oct 16, 2013, at 2:30 PM, Andrew Baerg <<a href="mailto:andrew.baerg@gmail.com">andrew.baerg@gmail.com</a>> wrote:<br>
><br>
>> On Wed, Oct 16, 2013 at 2:14 AM, Stefan Hornburg (Racke) <<a href="mailto:racke@linuxia.de">racke@linuxia.de</a>> wrote:<br>
>><br>
>> In general, it would make sense to have a generic shipping ecosystem for<br>
>> Perl + Interchange. But I'm sure there are a few things which can be discussed<br>
>> resp. enhanced in Shipment, e.g.:<br>
>><br>
>> * use a better way to address the services instead of ->ups, ->...<br>
>><br>
>> I had actually not intended the Shipment module to be used directly. I have to confess that this is my first module published to CPAN. I had asked for help to get it published and this was one of the things that someone else did for me. There are definitely some areas where I could use some mentorship from a Perl guru to steer me in the right direction. :)<br>

>><br>
>> One of the main goals was to provide a consistent interface to the various shipping services so that you could do the following regardless of which service provider you were using:<br>
>><br>
>> my $shipment = Shipment::XYZ->new(<br>
>>     from_address => Shipment::Address->new( ... ),<br>
>>     to_address => Shipment::Address->new( ... ),<br>
>>     packages => [ Shipment::Package->new( ... ), ],<br>
>>   );<br>
>><br>
>> $shipment->ship('ground');<br>
>> $shipment->get_package(0)->label->save;<br>
> I'm glad this came up. I was just working on this today.<br>
><br>
> What to we do when different carriers offer different services that will not fit into our predefined, generic services?<br>
<br>
</div>For different services your Shipment::XYZ can implement a method on top of what Shipment offers, let's say<br>
fuel_surcharge, which is not implemented by Shipment::ABC.<br>
<br>
In the generic code calculating the shipment price:<br>
<br>
if ($shipment->can('fuel_surcharge')) {<br>
    $shipping_cost += $shipment->fuel_surcharge;<br>
}<br>
<br>
Just an example.<br></blockquote><div><br></div><div>Yes, this has been implemented for example in Shipment::UPS where they offer a carbon neutral option which can be set with<br><br></div><div>$shipment->carbon_neutral(1);<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> I think in the example above we will have to assume each carrier offers essentially the same services which may not be the case.<br>
><br>
> In interchange we usually do something like:<br>
><br>
> UserTag ship_cost<br>
> blah, blah, bah<br>
><br>
> shipping.asc:<br>
> f [ship_cost mode=GROUND_HOME_DELIVERY]<br>
><br>
> Today I messed around with an approach like so:<br>
> shipping.asc:<br>
> f [ship_cost carrier=FexEx service=ground]<br>
><br>
> In my first example we have to assume each carrier's service (or mode) has a unique name of pass in a carrier parameter.<br>
><br>
> In the later example we'd have to limit the generic services to the once provided by all the carriers used.<br>
><br>
<br>
</div>Shipment should define standard parameters for the constructor, Shipment::DEF can have additional parameters.<br></blockquote><div><br><br></div>The base class where standard parameters are is currently Shipment::Base<br>
<br></div><div class="gmail_quote">Andrew<br></div></div></div>