by Quade (Posted Tue, 25 Mar 2014 22:25:58 GMT)
It's not really a matter of states. It's a matter of who ends up doing the processing. The RAR/PAR processing is handed off because if you try to do it in the download context, the download will stall. Every file that downloads is examined as it's assembled and added to the PAR tracking. I know if it's good or bad well before the last file is processed. You can see it in the properties window of any download that has par files.
Then if I want to do this on the fly unrar, I'll need unrar theads. One thread per unrar set because the RAR library isn't designed to do partial unrars. To stall an unrar and wait for the next file, you actually have to pause in a callback function and wait for the next file to show up. The thread has to accept abort commands too for cases where a RAR downloads damaged. It has to handle out of order RAR files too.
No matter what happens, there are a bunch of moving parts.
An alternative design might be to make the PAR processor do it and lock it down to a single set of rars at a time. Then the download would continue and out of order rars would just stack. That might be an interesting thing to explore. Fewer moving parts and if the unrar fails, I can switch right over to repair mode.
I'm working on Android right now. Probably won't look into it in any depth for a week or two. Android could probably make use of it too so, the unrar isn't backloaded.
Read Main Topic
It's not really a matter of states. It's a matter of who ends up doing the processing. The RAR/PAR processing is handed off because if you try to do it in the download context, the download will stall. Every file that downloads is examined as it's assembled and added to the PAR tracking. I know if it's good or bad well before the last file is processed. You can see it in the properties window of any download that has par files.
Then if I want to do this on the fly unrar, I'll need unrar theads. One thread per unrar set because the RAR library isn't designed to do partial unrars. To stall an unrar and wait for the next file, you actually have to pause in a callback function and wait for the next file to show up. The thread has to accept abort commands too for cases where a RAR downloads damaged. It has to handle out of order RAR files too.
No matter what happens, there are a bunch of moving parts.
An alternative design might be to make the PAR processor do it and lock it down to a single set of rars at a time. Then the download would continue and out of order rars would just stack. That might be an interesting thing to explore. Fewer moving parts and if the unrar fails, I can switch right over to repair mode.
I'm working on Android right now. Probably won't look into it in any depth for a week or two. Android could probably make use of it too so, the unrar isn't backloaded.
Read Main Topic
