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