Edward Lee schrieb:
> Gervase Markham wrote:
>> Edward Lee wrote:
>>> 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).
>>
>> That makes sense to me.
>
> But does that channel implementation seem reasonable? Nils?
I don't like it in channel. It is pointless to check if the consumer
won't use it anyway (and verifying hashes for large streams will consume
some time).
Having it in download manager (or whereever it may make sense) seems to
be the better idea IMO.
This is especially true when/if the built-in dlman later gets full
pause/resume capabilities (which requires ranges to be efficient).
So the dlman would have to check the file, once finished downloading,
anyway (again).
There is some basic pause/resume support already, but I never looked
into the implemention, so I cannot tell how it is done (my guess would
be ranges too).
As ranges cannot be checked, implementing it at channel level would
prevent hashing for a hell lot of use-types.
Or would require fetching the whole file again, which would be a waste
of bandwidth.
I still would favor my suggestion to implement a reusable tool-service
that will be used by dlman and other components who would like to have
that support.
Something like this (quick thoughts), basically a wrapper around
nsICryptoHash + parsing the hash out of nsIUri.
interface mozChecksumVerifier {
const unsigned long FAILURE = 0;
const unsigned long OK = 1;
const unsigned long UNSUPPORTED = 2;
unsigned long verify([in] nsIVariant aUriOrSum, [in] nsISupports
aFileOrStream);
}
This would be reusable, even by extensions.
> It's still up to the channel users to decide if they want to handle a
> failure status OnStopRequest. dTa can do what it'll do for the next
> version and ignore the status code and go on its happy way with the data
> it received.
If it is implemented this way (not a hard-fail, but a
let-consumer-decide) then I will have no objections.
> It seems that for the default download manager, which will be used by
> the average user, deleting the failed download is the right action. For
> those who are more advanced and use dTa, a dialog asking to retry,
> ignore, delete would be more appropriate.
>
> Ed
Would favor if the user is asked when using the regular dlman as well.
Reasons outlined in my other replies, and Micheal make comments as well.
But in the end this is not my decision, however I hope my opinion counts
as well ;)
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
