I am interested in joining the VM development team. I'm a consultant with over 18 years of experience in C/C++, 12 years in Java, and 2 years in PHP (my Resume is available at www.MikeMillsConsulting.com). I've used VirtueMart, as a store owner (it's a side business), for two years.

I have extensive programming, architectural, and project management experience. But I prefer programming most of all. Note that I am not a GUI developer - I'm not well-suited for HTML/CSS type development. I prefer to live in the guts of the system, and writing frameworks, where applicable.

For my initial contribution, I have some specific changes in mind for VM (note that I've talked with Soeren about them over the last few weeks.)

First, I have ready some logging and debugging enhancements: In a nutshell, the ability to log to a file, and also the ability to limit debug mode to a specific IP address. The current $vmLogger has been changed to be a composite logger, containing child loggers for display and file. This means that all existing log messages will now automatically get forwarded to the file logger (and will be written if the log level threshold is met.) The underlying $vmFileLogger and $vmDisplayLogger are also available to use directly.

Additionally, I have the following changes in mind:

1. Tracking number table. VM1.1 adds DHL label printing and tracking number support, but the tracking numbers should be externalized into its own table to support multiple shipping methods, and also to allow for per-sku tracking.

2. Order Payment History table (multiple phases.) First, the existing _order_payment table needs to be expanded to store additional transaction information from payment gateways. However, a bit further out I would like to create an order payment history table (or maybe a 'transaction' table). For example, an "auth" is a transaction that should be stored independently of a "capture" (for delayed capture.)

3. I have an existing XML export script that I use to integrate with StoneEdge Order Manager. However, it currently is dependent on hacks that I made to my _order_payment table. I'd like to make the changes in #2 above, and then make this script available to all (it can export orders, products, and customers - currently based on the StoneEdge XML Schema.)

4. Standardize delayed capture support (currently, PayFlow Pro and Authorize.Net payment modules have hacked-in support for delayed capture.)

5. Refactor payment modules and externalize some common functionality.

That's it in a nutshell...

--
Mike Mills
mike@MikeMillsConsulting.com