This is something that can be added in as well.

Basically, it would work as a "want ad" where a user posts something they are looking for, and the maximum amount they would like to spend, as well as the time frame -- end date, open, etc.

Sellers try to undercut each other to make the sale.

Some companies have tried this with different ideas, and twists, but the most reasonable use of this is a want-list.

Say you run a trading card site. A user would post I want card-A at $3.50. A vendor is willing to sell at that. Another is willing to sell at $3.25. etc.

Several users can post They want card-A at $3.50, $3.70, $3.52, etc.

Vendors can try to make a sale on any of those.

Question? Is this something you see a use for?
What about end-times? I can see it being a fixed-time-span, or "open". Or even user-ended.

Oh the power when one writes code :) <G>

Because of the potential many-to-one relationship this sets up, and only a one-to-one solution (for the most part) I don't see the viability of this as a real "auction", except where vendors have multiples of the item available (such as with duplicate cards). It would seem more like a "want ad".

That's why I'm asking. Any sites need something like this? Any ideas on how it should be implemented?

(I need a break from the templates <sigh>... boring! <G>).

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ

Hi pugdog...

Don't know if you heard or not, but E-bay will be licensing its auction application to companies...I know this doesn't totally relate to this Thread...but though you'd be interested:

http://www.ecommercetimes.com/perl/story/5403.html

As you know...I do not typically post sidebar topics, but I thought that others may be interested as well.

Regards,

Eliot Lee

That may be great for companies like IBM or Big_Parts_Maker. But, it will never be for the little guy.

And what technology??? :) They run on NT servers, that can't handle what is asked of them, with database problems and service outages :)

The more I get into this program, the more I see some subtle details that are taking some coding time, but 90% of the program is straight forward scripting with a single database query. The only one that is _not_ is the bid program, since a bid can be placed so many ways (and I'm adding in 3 or 4 different bidding options than ebay does.)

Granted, the reason this is possible is the time spent on the GT libraries it's running on, but that's what _I_ need, and I think that's what most links users want. If this thing looks like it could go "stand alone", as a separate application, I still wouldn't want to put the time in to develop the underlying libraries.

The auction process is very, very simple. It's not circular, recursive, redundant or non-linear. It's almost perfectly linear. At worst, it's a n-tree traversal. The problem I have is trying to not code it as an n-tree, since I can't figure out how to break out of a nested subroutine call without using 'exit;' Setting an error flag looks messy (although I've used it in one little area).

I'm trying my hardest to write clean, well organized code. If I was trying to hack this, I'd be done by now -- really :)

An ITEM is a link, with two additional tables (and once I figure out how alex uses the fk option it might even get smoother), but neither table has to be "joined" to it. The ITEM always has a winning bidder, even with proxy bids, there can never be more than ONE winning bidder (dutch auctions excepted, but dutch auctions are really, really problematical, since people don't understand them, and neither do sellers, and either the seller gets really hurt, or they use it simply as a way to clear out 5,000 items at the "bid" price).

Everything else ... check sellers items, check histories, email seller, hide emails, etc are all single run-through scripts. send_seller.cgi, view_history.cgi, etc.

I find it interesting that ebay is licensing the technology, from the standpoint of their current situation. They have 2% of the market, and they are slowing down already. Their valuation was cut 30% on a single analysts downgrade.

Yes they are profitable, but they are not a growth company any more, and they are trying to expand into areas where they see some "growth." Right now, they feel their "technology" is so great. Actually, _MOST_ other auctions have _BETTER_ technology. They just don't have the traffic. If ebay was going to license their traffic, _THAT_ would be something, but they have done what ever they can to prevent any cross traffic. Distributing their technology would be something like a bakery distributing raw flower and ingredients to the retail shops. Sure, you _might_ be able to bake bread, but you really need the bread already baked.


PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ

Well...I just thought you might be interested...sorry. I will think more carefully before posting this type of info in the future.

Regards,

Eliot Lee

No reason not to. I posted my take on the issue. I didn't know they were starting to license their technology.

News is always appreciated... but not all news is good news :)

I just don't think that it's going to affect anyone here, or almost anywhere. What makes ebay "great" is not their software, but the traffic they generate.

I just have very negative feelings toward ebay and their overall business and conduct model. If you pay them enough, you can get away with any of their rule infractions. If you are a little person, you get nailed even if the infractions were done by the OTHER guy. Talk with the sellers, and you'll know what I mean.

And, I'm just getting excited about this new program, since it's my first work with the NG program, and it's actually useful :) I've duplicated most of what ebay offers, and I'm trying to duplicate the best features of other software, or things I've felt were missing from auction software all along.



PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ

pugdog, do love your auction idea here, it is pretty amazing you are doing this to the script. I just hope some time you can port it into an "upgrade" for links sql so we don't require a new license, $450 is just going to be out of my league.

Also of interest, will you/do you think you will charge for this?

Really looking forward to all the extra features that can be added into links sql now that the plugin system looks so good - going to be exciting!

http://www.ASciFi.com/ - The Science Fiction Portal

Well, I wish I could say it would be free, and would not require a new license!

At this point I can't say either. Only because I'm writing this specifically for PUGDOG Enterprises, Inc., which means they technically own it. Like the postcards.cgi.

Depending on how the beta of Links looks, and how much I can figure out about how the categories are built, and the triad of databases Links/Categories/CatLinks are done, I might be able to pull this out as a plug-in on the second go-around.

It's _purely_ dynamic, I'm not even attempting to make it static. It _can't_ be. For a comparson, someone mentioned ebay: They have static catalog pages that can be as much as 5 hours old. That is useless, and it loads the system up with useless build cpu time. They don't do it dynamically, because of database/cpu load, but I have a feeling they _can't_ do it because of how they hacked their way past the problem in the first place. But, that is another issue. The point is that an auction site has to be "dynamic" -- more so than almost any other sort of general site. What good is a closing-soon, or going-going-gone area, if it's so out of date, everything's done-goneclosed <G>?

It might even be a good candidate for PHP, but I still have security concerns with PHP, that only time will address.

If I was building this under Links 1.1x I might have already had a version out .... Looking back I don't know if it's because it really is an "easy" type application, or because I've been thinking about it so long it just seems that way.

Right now the main script is the "bid" script, and it's 90% working. I can't debug it any further until I finish the the other scripts since it needs more data to work on, and those scripts are dependent on the templates... and each time I need a new template I have to add a new display routine... (Alex is addressing this so templates that don't need any special variables or routines set can share a single common parse routine.)

Once this is working, and I can get people to bang on it awhile, I'll see if I can't abstract out the logic that runs the core triad of files, and make it work without needing a new links install, and as an add-on to a site. I realize that as a plug-in it would be much, much more useful.

I also realize, that part of what a smaller auction site can offer is more features for both seller and bidder, and that requires dynamic access.



PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ

Had to spend a little time to rework some logic. Better to clean it up now.

I moved everything to using "objects" (well, technically they are really concepts, not true objects) as globals in each "function" (auction command or process). What this does is help make the flow of the program easier to understand and follow, while imposing as little overhead as possible (always the major tradeoff!).

Anyway, because Links runs as a "one user" system, and an auction functions as a two-user system (bidder & seller a.k.a. logged in user and "other"), there needs to be a $USER object which assigned to either $BIDDER or $SELLER than the other object becomes the other guy. Right now, I've had to create 5 objects: $ITEM (aka $link), $OLD_BID (current high-bid), $NEW_BID, $BIDDER and $SELLER

$USER was not sufficient to do anything but fetch the current user and put it into one or the other of the "auction objects."

I've also had to expand the number of fields in the $link record for speed/performance issues, even though it goes against the "database normalizing" theories. Before any "security" display, or any fetch/write operation I do check (maybe paranoid, but...) it will allow a more rapid display of the "item/link" in dynamic mode, by not making excess database calls, but any bid is made based on comparason of what would technically be "foreign keys".

Links SQL seems to have "fk" management built in, but current versions of MySQL don't support it.

For instance, if you want to send the seller a message, I could all the information from the current "display" of the page ....

eg:

<A HREF=<%db_cgi_url%>/send_seller.cgi>?ID=<%ID%>&Seller_Name=<%Seller_Name%>&Username=<%Username%>

But that is a _risk_ that allows for easy spamming.

If instead, I just accept the ID=<%ID%> as the passed in parameter, I can get the "sender" of the message from their logged-in user cookie status, and I can get the "recipient" (eg: seller_name) from the lookup of the $ITEM record (where I also can generate a subject, and other specific info) I've now bypassed that risk.

Would this be considered paranoid??

I'm viewing this as an ecommerce application, and I'm trying to plug security holes BEFORE someone finds them.

Basically: I can take short cuts on "item display" features, but anything that accepts user input has to verify it _FROM_THE_DATABASE_ records, not from _ANY_ user input.

For instance, all I need to place a bid is the $bid_amout and $ID of the item. Everything else is _in_ the database, and I have to call up those records anyway to update the bid info.



PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://postcards.com/FAQ