Module development and code questions

I'm integrating ilohamail ( http://www.ilohamail.org ) into drupal as a module for my ISP's homepage ( http://www.pioneer-net.com ).

The biggest catch (I hope) is implementing an alt auth method for drupal, so that users who have email accounts with us will get a drupal account automagically on login.

Here's what I want:
When the user posts a login attempt, check against a list of usernames stored in a db table. If the name matches, use the custom auth through ilohamail. If the name doesn't match (or auth fails, possibly indicating that mail is down), authenticate normally.

I recognize that for most deployments, it will be fine to just have a webmail login block that users see if they have webmail permission. That's fine, and I will implement it. For my deployment though, I need the above behavior.

I've been messing around with user.module and hook_auth a bit (this is a mod for 4.5 btw - if using HEAD is a good idea for some reason, let me know), and it seems that custom auth methods are only tried if there is an @ sign in the username. I don't want users to log in as user@host, just as user. So I will have to modify this function, I think.

The other tricky thing is that I want drupal to set the password for the user's account to her mail password on successful mail auth. If the mail server goes down, she should still be able to access the website.

The immediate reason for this post is to solicit sources of further info (aside from API) on auth methods, as I can't find much, and also advice on implementation details, as I am a drupal n00b (been hacking on it for a month tho, so learning).

I've been hacking at drupal for several months now, customizing modules for clients' sites, and a persistent frustration is that when something isn't working, it's difficult to figure out what's going wrong inside functions that don't produce any output. Normally, I'd debug by adding print statements to my code, but these generally get ignored by drupal.

it would be nice to see a module developed for drupal, that would use CRON and CVS to keep a live website updated to the latest changes in the drupal CVS system (while preserving conf/settings files of course). something like this would also need some way to *know* to update the sql when needed (maybe have a script that would compare installed version of drupal against latest version/date in CVS, and run any sql changes that have been made between those dates? i doubt this is possible without alot of trouble tho)

The readme for Organic Groups says "All subscriber management happens on the 'user list' page which is linked from the group Block (while viewing a group page). This includes approving subscription requests (for selective groups), unsubscribing users and promoting users into group admins."

What I can't figure out is, how do regular, non-admin users request to subscribe? I can't add any users from the page described above, only see already existing group members, of which there is only one--me the creator of the group....

Recently I wrote a suite of PHP4 classes for handling intellegent writing and reading of syndication feeds.

The suite uses a Factory Pattern approach to constructing an appropriate object to read a feed given a feed url, or to write a feed given a format. Each object (obviously) uses the same interface to provide access to the items and feed meta-data.

I have readers and writers for RSS 0.92, RDF 1.0, RSS 2.0 and Atom 0.3 available.

The code is under the ZLIB license as I wrote it with two initial uses in mind, the first being to re-vamp the Geeklog syndication system, the second being a commercial PHP application I am working on.

This should make it a viable option for integration into agregator.module for 4.6 to provide a more flexible and extensible way of handling feeds, plus providing more format options out of the box. The same classes could be used to generate the feeds that Drupal provides itself, or for any other module.

We have a bricks & mortar store so we have credit card processing through our bank. What we need in our ecommerce web site is the ability to take credit card info using SSL and then all the data would be hashed with Md5 and stored in the database.

Ideally the encrypted orders would be sent to two email accounts. A primary account and a redundant account. the emails would be decrypted on our computer and processed.

Alternately, as administrators we would go to the site and pick-up the orders decrypt them and process them manually through our merchant account.