Re: RFC: Package Shipping Modules

First, I want to say ++ for the amount of thought you have put into this, both on this post and your previous one.

Would this be a worthwhile & useful project?

Depends on your goal.

If it is a learning project and you want hands on experience understanding just how terribly hard it is to build multi-anything support that really does make life easier, then go for it. This problem is sufficiently complex that it is likely to be a good learning experience.
If the goal is to actually use the software, then "worthwhile" means something very different. Something is always worthwhile if there is a market. I'll take it as a given that people need to support multiple carriers in their information systems. The question is who and where are the people that would use ShipAPI? You? Start-ups who need to support multiple carriers and don't yet have the IT infrastructure for it? Software vendors selling systems to start-ups who are sick and tired of their current multi-carrier implementation? Enterprises and outsourcing shops that need to update their infrastructure?

Before you invest a lot of time, be sure you have a market - even if that market is you. My rule of thumb for markets of one is this: decide how many carriers/data formats/etc I need now (and in the near future). Calculate the time needed to write and test N almost alike implementations for those carriers. Now compare that with the time to implement, test, configure, and test configurations of a generic solution. Whichever is less wins.

Any ideas to contribute?

If you really want to understand what makes carriers similar, focus real hard on the data. Processes change much faster than data. Process and data are always, to some degree, related. But in most cases, you can change how you do your job much more easily than you can change what you need to know to do your job.

UPS, DHL, etc have been using the same data for years. XML, REST, SOAP - they are merely the favored processes and representation of the day. They change.
You've talked about similarities, but to make this work, you really need to focus on the differences. It is always the differences that make these problems hard to solve well.

Anyone want to tackle this? Or help out?

The most likely people to help will be people that want to share your learning experience or are are also facing the problem of supporting multiple carriers. The common bond at PM is software in general and Perl in particular. You'll find people happy to use a Perl solution and maybe even learn with you, but not necessarily people that have clients/are themselves dealing with a multiple carrier support problem.

To find people that need to support multiple carriers, you'll need to brainstorm a bit about who is interested the specific issue of supporting multiple carriers and are unhappy with existing solutions - enough to donate time or money to the issue. Then you'll need to figure out where to reach them - on or off line.

Hope that helps a bit, beth

Comment on Re: RFC: Package Shipping Modules

Replies are listed 'Best First'.
Re^2: RFC: Package Shipping Modules by hangon (Deacon) on Mar 31, 2009 at 20:53 UTC
Thanks for insight ELISHEVA. While supporting multiple carriers would be useful, my intent was to also address the following. A developer would only need a single API to write applications for different shipping carriers. If a developer writes an application using this module, and later the client decides to use a different carrier, it would not require a major rewrite of the application, just installation of the appropriate carrier module. By incorporating the heavy lifting in the core module, a carrier module could be easily written for even the most obscure shipping company or postal service. When carriers change their API, only the carrier module would need to be updated. You bring up a good point about processes. Though it appears that XML is the protocol du jour, there are probably others in use. My guess is that, for instance, UPS will not arbitrarily make major changes that affect their customer's ability to do business with them, but that's no guarantee. So perhaps another part of the project would need to be a set of plug-in protocol handlers. By worthwhile I am trying to find out if there is an interest in having something like this available to the Perl community. It seems it could be especially useful to web developers, and would be another excuse to write e-commerce applications in Perl. Since I find this problem interesting, in a perfect world (where I had all the time needed to do whatever I want) I would work on this thing as long as my attention span lasted. But since the world is not perfect, I'm throwing the idea out there to see what happens. If this project has enough merit, maybe a group will coalesce to collaborate on developing it, and would let me participate. update: added another item to list	[reply]

Replies are listed 'Best First'.

Re^2: RFC: Package Shipping Modules
by hangon (Deacon) on Mar 31, 2009 at 20:53 UTC

Thanks for insight ELISHEVA. While supporting multiple carriers would be useful, my intent was to also address the following.

A developer would only need a single API to write applications for different shipping carriers.
If a developer writes an application using this module, and later the client decides to use a different carrier, it would not require a major rewrite of the application, just installation of the appropriate carrier module.
By incorporating the heavy lifting in the core module, a carrier module could be easily written for even the most obscure shipping company or postal service.
When carriers change their API, only the carrier module would need to be updated.

You bring up a good point about processes. Though it appears that XML is the protocol du jour, there are probably others in use. My guess is that, for instance, UPS will not arbitrarily make major changes that affect their customer's ability to do business with them, but that's no guarantee. So perhaps another part of the project would need to be a set of plug-in protocol handlers.

By worthwhile I am trying to find out if there is an interest in having something like this available to the Perl community. It seems it could be especially useful to web developers, and would be another excuse to write e-commerce applications in Perl.

Since I find this problem interesting, in a perfect world (where I had all the time needed to do whatever I want) I would work on this thing as long as my attention span lasted. But since the world is not perfect, I'm throwing the idea out there to see what happens. If this project has enough merit, maybe a group will coalesce to collaborate on developing it, and would let me participate.

update: added another item to list

[reply]