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 PROTECTED]> writes: [...] > I'd be more concerned about the updates. Make ::Data subdistro of > it, like brian d foy has done with Business::ISBN and > Business::ISBN::Data. 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 CPAN. Chris Josephes <[EMAIL PROTECTED]> 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 installation. > 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 1999. 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". ----ScottG.
