Refactoring jbidwatcher

Subscribe to Refactoring jbidwatcher 4 post(s), 3 voice(s)

 
Avatar nekrad 25 post(s)

Hi folks,

I’m currently planning to use parts of jbidwatcher in my auction agent platform
(http://auctionwatch.metux.de/) and first do some refactoring:

a) use my small classlib (metux.util) and move a few common classes there (ie Base64).
b) separate the ebay logic from gui and move it to its own library.

Any comments on that ?

cu

 
Avatar Morgan Schweers Administrator 1,204 post(s)

Greetings,

Well, I’d hold off a bit, until I open up the subversion tree for the JBidwatcher-E version. (The non-1.x version of JBidwatcher; I never really decided what to call it, so it’s JBidwatcher Evolved for now. :) )

The JBidwatcher-E source is…heavily refactored. Still more to do, but it’s got some really deep changes in it. Among other things, it’s been package-ified, and the massive ebayServer class has been factored out into 10 different classes.

It also has a com.jbidwatcher.util package, for example, which is where Base64 (and many other) classes ended up.

I’m really uncomfortable making changes to the 1.x series right now, because I just went through a massive porting effort, moving all the changes I’d made between 1.0 and 1.0.3pre1 into the subversion tree. (Since a lot of it was for eBay changes, that meant extracting changes made to the one big ebayServer.java file into the 10 different files. It was very frustrating, and I’m not looking to do it again.)

I’m trying to get an embedded database datastore up and working, right now, and I’ve been thinking that once the DB read/write works reasonably well, I’ll push the codebase out and let people start playing with it. (Not officially releasing it, as it’ll still be a bit raw from the refactoring.)

If you can wait a bit, you’ll find a substantially more useful source tree available.

THAT SAID… I hope you aren’t going to be building a sniping web service. One of the points of JBidwatcher is that sniping web services are bad things, and that sniping should be done on your local computer, so you can keep your username/password information secure.

If you’re building an auction search site (which is what it looks like from your page, at least via babelfish), I’d personally recommend going with eBay’s API over using JBidwatcher’s code, even improved as it is. JBidwatcher scrapes the HTML because it has to. If you’re just doing searches and displaying auction info, you really want to be using the API, and it’s easy to do… Plus, if you use eBay’s API, you can be on their affiliate program, and make money off of it.

Heck, I really want to be using the API (and their affiliate program), but as the author of a sniping program, I can’t. :(

— Morgan Schweers, Cyber*FOX*!

 
Avatar Destro 8 post(s)

I came to the forums today to ask a question related to this discussion, which is “How do the Sniping Web Services work if they don’t use the API?”

They don’t seem to have the problems with changing page text like JBW, even one of the free ones I have used, so I assumed they were using the API.

 
Avatar Morgan Schweers Administrator 1,204 post(s)

Greetings,

The sniping services have one place to change their code, and if they do it quickly, nobody else after that notices.

With JBidwatcher, because it runs on your local computer, I have to package a release for people to download. Even if I’m really fast about it, the lag time means a lot more users get affected. Also, there’s always stragglers who don’t get the update notification, for months afterwards.

I don’t like the idea of the sniping services, honestly. They bother me, and I don’t think that people should use them, and I don’t like the idea of JBidwatcher’s code being used in them. The thing is, though, that I don’t think that JBidwatcher’s sniping engine is very useful to most sniping web services.

They don’t need to worry about a lot of the things that JBidwatcher needs to worry about. Their network timing is going to be very consistent, they don’t need to show a constantly updating UI to the end user, or handle mouse events, drag-and-drop, or even usually parse the actual item page HTML. Usually they just place the bid, and don’t worry about the result page. JBidwatcher, because it tries to present result information, parses the post-bid page. So while the sniping service can just look to see ‘Hey, did they win?’, JBidwatcher tries to evaluate whether you lost because your bid was too low beforehand, or if someone else outbid you afterwards, or if the seller is refusing to sell to you for some reason (wrong country, no PayPal, etc.).

JBidwatcher would probably be much simpler if it just tried to manage whether you won or lost, but it really tries to evaluate the responses, so you understand why you lost, if you did.

Anyhow, the result is that sniping services generally have it much simpler, and as soon as they make the change that makes it work, every one of their users (and bidders) are all automatically updated.

The problem is that in exchange for this, you have to give them your username and password (and sometimes money).

You can use JBidwatcher like a sniping service; place your snipe, and just look after the fact to see if you won or not. I’m actually working on adding more capability to do just that. (Not logging in except specifically when placing snipes.)

Hope this brain-dump helps. :)

— Morgan Schweers, CyberFOX!