Using cURL to send the results is going to get you a lot of lost data. Windows doesn't have curl, and Unix's only tend to have it if either a) the distribution included it by defaultl or b) the user prefers curl and installed it themselves. Either way, it's yet another 3rd party dependancy to build a demo app. Not worth it in my opinion. If you really want it up upload it's results to a webserver, the code required to make a client perform an HTTP POST operation is actually rather small, and since IPv4 network sockets are always available on all Internet connected Unix and Windows boxes, your available testbed is much larger. Mainly though, it's the extra dependancy on a 3rd party app purely for a test application that makes the use of curl a bad idea.However, the idea of a performace testing application is actually pretty good. To be realistic though, you can't simply throw a few polygons on the screen and expect to get an accurate FPS count. You need to actually stress the hardware, which means doing things that are "hard", and thus don't always look good. Try rendering a tree, and have all of the individual leaves blow in the wind slightly differently, then in different passes start adding new non-ambient lightsources, and then in yet another pass attempt to perform different shadow methods. The goal is to work up from something easy to something very hard. Ideally, you'll start at about 200+ FPS, and end at about 10 FPS. If the hardware cannot keep up with a particular pass, then moving on to the next one is a little pointless, so you should stop.
If you want a good idea of simulated realistic benchmarking, go checkout Futuremark. These are the same guys that made all the Mad Onion benchmarks back in the day, and 3DMark is still one of the best simulated realistic benchmarking utilities that I've seen to date.