Re: [PEPr] Comment on Networking::GeoIP

Hi Stefan, Pepr wrote:

Stefan Neufeind (http://pear.php.net/user/neufeind) has commented on the proposal for Networking::GeoIP.

Comment: I think it would be nice to have this added. But maybe it could function as an abstraction via various databases available for basic information?

Well, I think it might make sense for Net_Geo or Net_Ip2Country (or I18N_IP2C) to abstract several of the different ip-to-cuntry lookup systems, including GeoIP. This class, though, is very focused on the particulars of GeoIP, and most of the code is not even used for basic IP2Country lookups. Having this be an abstracted API would not be useful because the abstraction could only contain the lowest-common-denominator (ip-to-country). Just generally, I also don't really see much value in abstracting the geolocation lookup API. I know that this is a popular practice in PEAR :) There are a few reasons for my feeling this way: 1) Unlike (e.g.) choosing a template solution, Net_GeoIP corresponds to a specific product by Maxmind. When you choose GeoIP as your solution, you are first choosing to use (and possibly buy) the Maxmind product. 2) Again, unlike templates or DB, I can't really imagine this package being integrated in any other PEAR packages. I think a package that sought to integrate such a tool would be better off as a standalone application. That said, I think a good solution for PHP5 packages like this one is to create some interfaces. If there were a I_Net_IP2Country interface, then Net_GeoIP could implement that interface. I would imagine such an interface containing one or two methods (like lookupCountryName()) -- i.e. the only methods that any integrating package would care about. On a side-note I think this would also be a good move for PEAR in general, as it would address the issue of inter-operability while allowing for package competition. For exmaple, w/ templates, let the different engines exist w/ their customizations & special features, but have them implement a very basic interface that would contain methods like assign(), display(). Packages that use templates could just be passed an object that implemented ITemplate and they could perform their assign operations & display it. The difference to what I've seen suggested so far, is that this template interface needs only to have a bare minimum of functionality & the engines can provide many additional methods that would be used by the user code. The idea isn't to limit what a class can do (as seems to be the case w/ single base Template class), but rather to provide a contract that lets other packages use the basic functionality that they need. Hans