A private emailer wrote:
Even better isn't all this on a USPS server? Whatever tool you use
to grab their server database, include it and do that as part of the
build process or perhaps offer it as an option , the alternative
being to go to the USPS server every time.
Three things I don't like about that. First, it gives a single point
of failure for the system, as compared to relying on CPAN's large
network of mirrors; worse, it would break if USPS's server ever
changed the file location or format. Second, if you want to use
something like CPAN on CD to install onto a non-Internet connected
machine, downloading from an external server will break; you'll have
to arrange for that one file to be copied over and installed by hand.
Third, if you cache CPAN modules for installation to many machines,
this will bypass the cache.
Andy Lester <email@example.com> writes:
I'd be more concerned about the updates. Make ::Data subdistro of
it, like brian d foy has done with Business::ISBN and
Right, the data is in a new module called Geo::PostalCode::US;
Geo::PostalCode is the main module. The code for Geo::PostalCode::US
is 26 lines plus some cleverness in Makefile.PL, so I'm not too
concerned about seperating code and data for this module.
When the code updates, you don't have to push out half a gig again.
Just to be clear, it's half a meg; I wouldn't put half a gig onto
Chris Josephes <firstname.lastname@example.org> writes:
Is the data currently encoded in a standard format? How difficult is it
for end users and developers to get updated copies of the data. [...]
One concern I would have is how dependent would your users be on you
to be the primary provider of the data updates?
The main Geo::PostalCode module provides easy instructions for
generating your own location database from a simple tab-seperated
value file. Geo::PostalCode::US is just for easier download and
Would updates always be in the form of a re-versioned perl module?
Yes. They'd be very infrequent. The data we're using now is from
I'm working on this in response to a user on PerlMonks who had a very
difficult time getting Geo::PostalCode installed and set up right on a
hosting provider. It's much nicer to be able to install it with the
standard "perl Makefile.PL; make; make test; make install".