match local and remote users

First, thanks for the great module and timely update to D6!

Here is a feature query related to several previously proposed issues (which I'll also mention in this post). They can be satisfied with the same feature --- some matching and integration between the local and remote user database.

Our motivation example is like this: We have a community powered by Drupal, we also use Google Apps for other services (mail/chat/docs/calendar). So basically, we got 2 independent user databases, even though every member has the same name in both systems. This is obviously hard to maintain for both us and the users (they can change their passwords independently in both systems!). Obviously, we want to integrate these two, at least for authorization.

The typical solution is to use the Google Apps Auth module (http://drupal.org/project/googleauth), which let you only maintain your Drupal user database and the Google Apps will authorize against your Drupal authorization service. This is nice, except this so-called SSO feature is only provided in Education/Enterprise edition, not the free Personal/Community edition.

That's how the wonderful imap_auth module comes to rescue. Unlike the SSO solution whose user database is on the Drupal side, we can now authorized both systems against Google's IMAP/POP3 service, then we can just maintain the user database on the Google side.

However, there are still some problems with this solution:

* Now all users in the Drupal system are considered external, and appear with the funny '@myhost.net' in ID even if they're actually at http://myhost.net, see issue 142806 (http://drupal.org/node/142806) for more details
* Usually, we have already got a lot of users registered in the Drupal database. With this solution, everyone should now login with "id@myhost.net". Considring "id" and "id@myhost.net" are not the same thing even at http://myhost.net, the configuration and history can't be shared between the two accounts of the same user. See issue 75258 (http://drupal.org/node/75258) and issue 103605 (http://drupal.org/node/103605) for more details

So even with imap_auth, we may still want some integration between the two. The integration means:

* "id@myhost.net" and "id" should considered the same at http://myhost.net, and better as a local rather than an external user
* The admin only have to create "id" on the Google side --- it should be propagated automatically to the local Drupal system when necessary (We can't do the reverse , since Google doesn't provide such API), so that this "id" can also login to the Drupal system locally
* since the Drupal's and Google's user database are actually independent, and the users can change their passwords in either or both systems arbitrarily, so the password synchronization methods can be one of
- always the same: i.e., always use the external imap authorization. This is the simplest, but most inefficient one
- caching: the local Drupal password is a cached version of the remote Google's service. The user can change either or both of them at any time, however as far as he can give one of the password correctly, he can login. The Google password will be propagated when the user starts to use it to login to the local Drupal system.
- independent: the local and remote passwords are considered independent. There is no propagation, except the first time when a "id" is created in Google side but not yet in Drupal

All these are under the precondition that the domain name in the login id is the same as the domain name of current Drupal system, or the id is not a email but a plain indentifer. All other ids such as "id@otherhost.net" are not affected.

Based on this design, I did some preliminary experiment which seems to be working, but the code currently needs more polish (I don't know PHP, so I just copy and modify code). Other changes include permitting login with registered email etc.

I'd like to contribute it as patches, but I'm not sure whether it against the simple philosophy of imap_auth itself. If you think this design should be integrated into imap_auth, I'm more than happy to collaborate, otherwise can I derive a new project from here? Since this module is very important to our community's infrastructure and I will have to maintain it anyway.

Thanks