ok, I have impletmented 2 1/2 versions of something like this in java, so I can probably help you with some of the problems that you will run into. (I am working on the third at the moment, It will be about a 50k download, and will do all the things that have been listed already,)
Really, I think your Idea is a better way, sql databases are definately the way to go - A lot of the program is going through the data base to see what frames (I stored everthing as frames, each with a blend file name, the name of what ftp server that file is on, and i will implement checksums, so that clients can keep a local cache of files, so that when someone redoes a render with a slightly better texture, no new ones have to be downloaded) suit the querying machines ram etc.
The only real bottleneck in this system is the network speed, so I advise
- Save things as png’s - these can have up to 64bits including alpha layer, and re compressed very nicely.
- Have support for multiple file transfer protocols - you will know the best way to do this with c++
- Ummm, don’t use packed textures - If they are seperate, they can be cached as above.
- The recieving server (the one that is getting the frames back) and the sending server (that is handing out blend files) should be able to be seperate.
I m going to finish my java version of this, as I will probably end up adding support for a sort of blend cvs (using linked objects) nd various other functionality. If you run in to any problems, email me (bobthevirus[at]orcon.net.nz) and I can tell you how I did it, but more importantly than that, how I did it for the fiirst two versions (which didn’t work.)
Also, contact me if you have some set php/mysql tasks, or for bug checking, or whatever. I can’t promise I will be of use, but I will get back to you immediately if I can’t do something, so you can give it to someone more skilled.