Nils Maier wrote: > If you still want to implement this on a channel level, this approach > sound reasonable.
I didn't explain things well earlier and probably gave you the wrong picture of how I've implemented Link Fingerprints. I'll try again.. The channel acts just like before Link Fingerprints, except now /after/ the transfer has finished (meaning the download manager and dTa, which is getting data by chunks, have all the data that they normally would have gotten), the status code provided by OnStopRequest will report a failure code if the Link Fingerprint failed. The only exception that there's an early failure if the Link Fingerprint is invalid. We cancel the connection early because ideally, the channel consumer is going to notice the Link Fingerprint failure and report failure, so this prevents wasting the end user's bandwidth (which could cost a lot of money in some places). > So I still am in favor of implementing LF within the actual consumers, > as only they know how to handle stuff correctly, as only they got the > full stream. Link Fingerprints /will/ need to be implemented in the actual consumers because the only difference is that the channel might provide a new failure code after the transfer is finished. If existing consumers *don't* have a catch-all action for any general failure, doing Link Fingerprints in the channel doesn't affect them at all. To give a concrete example, the new code for dTa's Download object in manager.js [1] has the onStopRequest function that does NOT look at aStatusCode. The chunks will still write the data for onDataAvailable. When the onStopRequest arrives with the failed Link Fingerprint status code, dTa will work like normal as if nothing happened. Ed [1] http://bugs.code.downthemall.net/trac/browser/branches/maierman/manager-trees/chrome/content/dta/manager.js#L1575 _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
