I've been toying around with a wrapper program for proth_sieve (on Linux).

Apologies if this is similar to sobistrator, I don't do sieving on Windows so I've never seen it.

I had multiple machines running proth_sieve and wanted to keep track of them all without logging into them and wading through the logfiles.

My current wrapper program does the following:-

Checks the status of SoBStatus.dat (finds pmin,pmax and the last pmin value in the logfile).

If all is ok (i.e. there is no 'Done' message) it starts the appropriate proth_sieve client.

It then monitors the SoBStatus.dat file keeping track of the last line.

Every 30 seconds (this is configurable) it checks for new factors in all of the fact*.txt files. Once a day is a more realistic setting.

If it finds anything new (factors or a later line in SoBStatus.dat) it uploads it to a central server. I can then view the status of all of my sievers on one webpage (via some cgi-bin stuff).

I would need to move the comms layer from a proprietry protocol over TCP to HTTP GET/POST, but that shouldn't take too long.

Reporting back by HTTP GET/POST would mean it would be relatively easy to integrate it into both Matt's reservation site and also the factor submission pages.

This is an important point. I'm not suggesting a new website or central server. I would only do this if it is going to integrate into the existing systems.

It also takes a note of the size of the SoB.dat file, which can be checked against a central server to inform the user that there is a new and updated SoB.dat and that they should go and get it. It would also help identify the other (1M-20M .dat files) that are being used.

I'm redeveloping it in stages:-

1. Parsing SoBStatus.dat file giving a simple report to stdout.
2. Parsing fact*.txt files for number of factors in report.
(The above is similar to Matt's php script)
3. Checking file size of SoB.dat
4. Monitoring both of the above files
5. Uploading status to webserver
6. Uploading factors to webserver

Future stages (open for discussion):-

a) Running the proth_sieve client directly.
b) Logging in to webpage before uploading factors (would be required).
c) Logging in to webpage before uploading status (would be nice but not 100% necessary)

Further on from this is the possibility of automatic range assignment but given the fact that a standard 1T range takes most people 1 month it would probably be more work that necessary.

Benefits:-

1. Automatic submission of factors relatively soon after they are found.
2. Progress updates are submitted automatically and frequently (once a day).

Source code would not be released but I would share it with the appropriate people to get it compiled for the other OSs that proth_sieve is available for.