Functionality overlap with ip2cc module

All very good questions. Let me first say that I did initially try out ip2cc (among others) before I created my own module, but rejected it for several reasons I will try to explain below. The reason I didn't try to just patch ip2cc is that some of the differences are fundamental, and can't simply be patched. That said, I would be happy to consolidate these two modules if the differences can be worked out.

There are several other existing modules that address geolocation. Among them are:

• http://drupal.org/project/ad_geoip
• http://drupal.org/project/geoip (new)
• http://drupal.org/project/geouser
• http://drupal.org/project/hostip
• http://drupal.org/project/ip2nation
• http://drupal.org/project/ip2cc
• http://drupal.org/project/ip_locator (abandoned)

They *all* overlap to some extent, and I evaluated all the existing modules before starting my own. I'll follow up with a detailed comparison of all these modules, but let me just address ip2cc in this post.

I completely agree with your statement that

ip2cc also provides quite a bit of additional functionality, which in my opinion, goes above and beyond what it should be doing.

In fact, that's true of all the other modules as well, except the brand-new GeoIP which didn't exist when I wrote my module. Every one of them was created not for the purpose of geolocation, but rather for a specific *application* of geolocation. Because of this they all come with extra baggage or dependencies; none of them is general. And this is one of the main reasons I started my own module: I don't need all that other stuff, nor do I think it should be included in a geolocation module.

Likewise, all of them have "encumbered" databases, often requiring manual installation due to license restrictions. Some of these modules even distribute, along with the module, databases and API code that are not under GPL - in violation of Drupal's terms. This is the other main reason I created my own module. I don't think that databases, API code, etc. should have to be downloaded and installed manually, and I don't think that keeping the database up-to-date should be a manual task. I think the Drupal rules about including only GPL code in modules must be followed.

Now about ip2cc specifically.

The first issue I have with ip2cc is the database. ip2cc uses a database from webhosting.info, which is free but not GPL. webhosting.info derives their data from the RIR data, but it's not clear to me what the value added is. Do they verify the data, modify the data, do anything to it whatsoever? Without value added, this database suffers the downsides of using a third-party DB without gaining any advantages. The bigger problem is that webhosting.info only updates the DB "approximately" once a month. This DB is a CSV file that needs 1) to be downloaded and translated to SQL via a Bourne shell script included with the ip2cc module, then 2) manually inserted into your Drupal DB via a menu option. To update your own site with the new DB, you have to download it by hand then install the new version. IMO this ensures that no one will keep their DB up to date, greatly reducing the utility of the module. There's also the issue of cross-platform use - this only works if you have Bourne shell and MySQL. Plus, I'm uncomfortable with the reliance on a third-party product that shouldn't be distributed with the module.

In contrast, my module uses publicly-available data published by the regional internet naming registries. This data is downloaded and installed directly into your Drupal DB when my module is installed, so there is no manual step required. The RIR data is updated daily, and my module provides admin options for automatic updating of your Drupal DB with the new information via cron. You get to choose the update frequency, or you can update manually by pressing a button. The config menu shows the time of the last update. I also provide debugging options in my module, which allows a user with the correct permission to simulate an IP or a country for use in testing. In fact, I'd have to say the vast majority of the code in my module is there to handle the admin menus and the database updating. The actual IP to Country mapping is just one DB query.

Another problem with ip2cc is that it throws in all sorts of other stuff that IMO belong in separate modules. I'm glad to see you think the same way! ip2cc seems to be intended mainly for inserting a country flag in a comment/node to show where the comment/node author resides. Admin options let you choose node types to display flags for, and whether flags are shown in comments or not. ip2cc includes an ISO 3166 database and a set of flag icons for every country, both of which I see as totally unrelated to the module function and inappropriate for inclusion into the module. If flag icons are useful, for example, they should be in their own module so they can be used for many different purposes. It's wrong to tie the flag icons to the geolocation and vice versa.

Another problem I see with ip2cc is it is inefficient - it JOINs the entire ip-country DB to the ISO 3166 DB at every call (ack!). It uses hook_link to add the flag to nodes/comments, which I find to be a questionable choice. I don't like the 200+ .png files which accompany the module. It would be better for webserver performance to serve just one large file which combines all the flags, then display only a slice at the client side. The inefficiencies are the only issue that I thought could be addressed by patching ip2cc.

At the time I developed my module, in July 2008, ip2cc hadn't been worked on in more than a year, and it didn't look like it was going to be ported to D6. It did not conform to Drupal coding standards. So in addition to my concerns above, I wasn't hopeful that it was a long-term solution. And I certainly didn't think I could get patches approved which removed the flag functionality or which changed the database used - even routine issues were not being taken care of at that time. I'm glad to see you have rescued the ip2cc module and have started to maintain it. That wasn't something I was counting on last summer though, and I had no desire to take on that task myself since I disagreed with some fundamental aspects of how the module worked. It was easier to write a module from scratch than to re-make ip2cc to my liking.

I have also noticed that whilst your project is called ip2country, it is in actual fact uc_ip2country, and I'm wondering, why is it tied to ubercart? This is functionality that is useful in many areas, not just ubercart.

I agree the functionality is useful for many things, not just Ubercart. Which is why I am so strongly in favor of separating the geolocation functionality from the application of that information (e.g. displaying flags based on country).

Right now there is only a small dependence on Ubercart. Specifically, Ubercart maintains a table of countries that a store sells to. My module, in the admin menu, allows the admin to spoof a country for testing purposes, but this spoofing only works for countries activated by Ubercart. The only thing provided by Ubercart is the country ISO 3166 2-character code to Country name translation for these activated countries. This dependence is ONLY for the spoofing function, and does not affect the core functionality of IP-Country lookup. This module can and should be changed to use the countries_api instead. When I first wrote it I wanted to minimize bloat, and the countries_api would add a lot of stuff that was not needed for the main function of this module and was not needed elsewhere in Ubercart.

I intend to port this module to Drupal 6 this week. After the port, I will see what I can do to integrate with the countries_api module going forward.

Finally, I didn't call my module Ip2Country - I called it "IP-based Determination of a Vistor's Country". Wordy, I know, but much more descriptive and no chance of being confused with "IP to Country" which is the title of your module ip2cc. The name was changed by VeryMisunderstood, a drupal.org admin, without consulting me. I don't think it was a helpful change.

Yes, I have a port almost ready to release. I plan to have it posted before the weekend. Maybe even tonight.

I don't think ip2cc is useless, and I don't think the current users would want you to throw it away either. But I think there are several distinct pieces of functionality here that should be separated. In essence just a refactoring of the code, no change in what the module accomplishes. The functions that can be separated are:

1) Pure IP to Country lookup
2) ISO 3166 Country information
3) Country flags indexed by ISO 3166 code
4) Module to display themed country information (i.e. flag) on a node

I think ip2cc can be repurposed to do just 4), with 2) handled by the country_api module, and 3) handled via a new CountryFlags module extracted from the current ip2cc code. I think my module can be used for 1). The end result would be a pure geolocation module based on the RIR data with no manual install or updating, two helper modules for country and flag information that would be of general use, while the original use of ip2cc would be preserved even as some of the pieces were moved to other modules. The new version of ip2cc would still be used the same way, so existing users would not lose anything. It would just have a few new dependencies they would have to install.

ip2cc was good choice for me until I found that it stores country codes in some strange format. For example, my country (Ukraine) is "UK" in iso3166, but in ip2cc it's "UA". I can't use this data to make joins with most of the modules. And there's no module which can convert one code to another. So, the ip2cc's database is a major minus of the module itself. Right now I making module with dependency onto ip2countries, as it stores database in correct ISO 2 letters format.

5.x is no longer supported

Let's leave this open - I think it provides some important information for users of this module and leaving it open makes it easier to find.