jk2addict has asked for the wisdom of the Perl Monks concerning the following question:

Long story longer. I've added currency formatting into some of my stuff (Handel / AxKit::XSP::Currency) and I want to add currency conversion as well. I know there are a few modules on CPAN for this.

First we have Finance::Currency::Convert that uses Finance::Quote. This seems to rely on many difference sources for conversion rates. Not bad, but a little bulky.

Next we have Finance::Currency::Convert::XE which has restrictions by XE.com on the usages/commercial/business/personal, etc.

After that we have Finance::Currency::Convert::Yahoo which relies on scraping Yahoo Finance. That's a little fragile.

So, this leads me to this service on WebserviceX.NET. It looks nice and predictable (SOAP/RPX/GET (RESTish)), free, no restrictions that I can find. There isn't a module on CPAN for this particular converter.

So now I have a few choices. First, I can write yet another currency converter and put it up on CPAN. Next, I could just hack in some quick GET/RegExp code do do this in my app.

If it were you, what would you do?

Update: Of course, the new modules should probably be named Finance::Currency::Convert::WebserviceX, just like it's Yahoo/XE counterparts. For that matter, it could mimic both ::Yahoo and ::XE API to be a drop in replacement. :-)

Replies are listed 'Best First'.
Re: Yet Another Currency Converter
by RazorbladeBidet (Friar) on Mar 09, 2005 at 23:05 UTC
    With any process that relies on external data, your source has to be stable and seldom (if ever) changing. All of these will rely on that, and that's what the problem is.

    I would say that (without delving into the depths of the modules presented) anything that can connect to reliable and accurate sources (multiple) would be your best bet.

    Without having immediate control of a feed, you will run into these problems anywhere, even in major corporations that talk only amongst themselves

    If Finance::Currency::Convert is too bulky, take a source as your primary data feed (e.g. Yahoo!) and use it unless it changes/dies/becomes innacurate, leaving the remaining sources to be used in that case.

    Which is probably what it does anyways :)

    Good luck!
    --------------
    It's sad that a family can be torn apart by such a such a simple thing as a pack of wild dogs

      Good points. I guess that's part of my issue. I don't really trust anything that does screen scraping, which rules out ::Yahoo. XE has usage restrictions. ::Quote brings with it a ton of fund and stock quoting stuff which isn't really relevant to a problem that can be solved by about 10 lines of code and a GET.

      My main driving force is that I don't want to write that 10 lines of code twice in two different. I figured something lighter and assumably more stable (using a webservice designed for remote use) would be usefull. On top of that, it removes the need to keep the conversion data up to date locally.

Re: Yet Another Currency Converter
by jk2addict (Chaplain) on Mar 10, 2005 at 17:34 UTC