UC Auction 2.0 status
| Project: | Ubercart Auction |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
After the company I work for found another client interested in auctioning products, I began work on Ubercart Auction 2.0, which I've been wanting to do for a long time. It's a complete rewrite of UC Auction, implementing improvements I felt would be necessary after seeing the problems people had with version 1.0, as well as just better coding style and such I've picked up in the time that's passed since I first started working on 1.0.
The major architectural change is that the core UC Auction module is implemented as an Ubercart feature and that it has very little code in itself to do things like validate, accept and store bids, determine who the winner of an auction is, etc. Instead, all of that is to be handled by an auction type module. The only auction type module in existence so far, intended both for utility and to be an example for future such modules, is a standard "Forward" auction type, for which there can only be one top bidder; bids must be higher than previous bids to be accepted; etc. The idea is that, if you wanted to have reverse/Dutch auctions, you could install or develop a module which provides a "Reverse" auction type, in which bids must be lower than previous bids to be accepted. Or you could add a module to do auctions in which the top X bidders will all be able to buy the product. Or so on or so forth. The idea is that this sort of thing won't require hacking UC Auction core anymore; you just install or develop a back-end module to do it. And it would also be no problem to mix and match different auction types on a single site; you just select the desired auction type when you create the auction and have at it.
I've been making decent progress, but there's a new layer of complexity that all this adds. Further, I'm not entirely sure that I'm taking the right approach in the first place here, because it just seems like I'm writing a lot of the same code, but just in a different place. I'm also concerned that it's going to cause a lot of duplicate code in the back-end modules; after all, really the only difference between a Forward auction and a Reverse auction would be the directions that the bids go. I might have to re-think the architecture a bit to avoid that, but that's more complexity…
I have some stable, partially-working code I could release, and perhaps I will, but another change to the 2.0 branch is that the module's system name is "uc_auc" instead of "uc_auction," which allows for shorter variable and function names and such, but I'm not sure of the implications of that for Drupal.org's CVS server - I might have to create a whole new project, or just rename everything back to the longer name. We'll see.
But getting back to our client interested in UC Auction, for now, I've decided to abandon the plan of using him as a UC Auction 2.0 guinea pig, and instead use 1.0 for his site. The rewrite is just taking too much time that we probably won't be able to charge for. So possibly expect a trickle of new commits to the 1.0 branch in the days ahead (I just made one today, in fact).
I'm still hoping for an "angel" who would be willing to fully subsidize UC Auction 2.0 development, either through my company or through me personally. (I'm cheaper, definitely, but I don't have eight hours a day to work on personal projects…)
I'd like to hear your thoughts.

#1
Sounds like a very good plan, flexible and straightforward.
I have a possibly interested client too, but its (again) not that enterprise size "angel", willing to spend big bucks on this. If this gets real I will contact you, maybe I can chip in or help out in another way.
Thanks,
Kees
-------
Handdoekenshop voor handdoek en theedoek