Haven’t seen this feature browsing the requests some time backwards, so I hope it’s not a duplicate.

For people who are short on money, but still would like to snipe some auctions, this might be an important feature: snipe auctions only as long as the successful snipes (individually configurable with or without postage each, as some of them might get collected personally, others are too far away and need to be sent) do not exceed a certain amount of money to pay; immediately stop sniping when the maximum available sum is reached, until a new sum is set again, which the user would do when he again has some money.

There’s a lot of things I’d like to snipe, but can’t for the risk of getting more of them than would be healthy for my bank account, although each individual snipe, or even some of them together, would be ok.

I’m not Morgan, but this is one of the many features that seems reasonable, but that he shouldn’t do. JBidWatcher needs fewer features, not more. Each little feature, however reasonable, is just a bit more code to maintain, and, as is pretty clear from the fact we haven’t had an upgrade to JBid in almost two years, there’s too much code already. Toss the web interface (which I frequently use), abandon multisniping (which I love dearly), forget the MySQL option (which I used for a while), if that’s what it takes to keep JBidWatcher alive and fresh.

Greetings,
This is, in fact, the direction I’m kind of going. I’ve eliminated the old web interface (I’m sorry!) including the internal RSS feeds and the cache view of item listings, almost all XML-related features, finally gotten rid of mature audience item bidding, eliminated a bunch of fallbacks for features that have been in Java core for years now, and a bunch of other features that were good at one time, but now are impossible to maintain. I’m using eBay’s in-page metadata and their API-ish ‘ViewItemLite’ public JSON when I can. I removed the crappy TableSorter code that’s been out of date since 2007, standardized on Java 1.8 (which I’m now shipping with it on OS X and Windows so folks don’t have to run on the Java upgrade treadmill)…

However, I also added a scripting language (Ruby) and implemented a bunch of features in Ruby, so they’re a little easier to iterate on. I also included Ruby features that will let me re-implement the web-server MUCH better (not quite Rails-in-JBidwatcher, but close!) if it’s useful in the future. (So can anyone who knows Ruby scripting, in fact!)

…

Now I’ve just got to release the !#$! thing. Which has taken me months, since it’s been in a reasonable state to ship at least as a pre-release.

As to the @jssr67’s original feature request, I presume it means, ‘Given a total of $500, snipe on these 12 items, but if the cumulative total would exceed $500, stop sniping’. It’s an interesting idea, but I won’t implement it. What I may do, however, is implement features that let YOU (or any other user) implement it in Ruby, maybe with some syntactic sugar to make it easier. Then a little bit of sharing, e.g. on the forum or in a repository of script addons for JBidwatcher, and you can browse through and find the feature you need/want…

As @Dave Howell says; I’m done making JBidwatcher more complicated. I’m going to start stripping pieces out of it, and (maybe) re-implementing them in Ruby, and (in some cases) making them optional.

— Morgan