Matthew Toseland wrote: > Is it better to report actual CHKs, or block numbers? Maybe we should do > both? We would only need block numbers for selective reinsertion (the next > logical step), although there isn't really any good reason not to report > CHKs.
For the use I had in mind, I don't think the block numbers are of any use yet. As you say, a following step would be to implement partial insertions. At that point it would be interesting to give feedback on the mapping blocknumber<->chk. > What about request resuming / finding blocks in the datastore? On starting a > request, we turn off SimpleProgress notification, because most of the time > the request is being resumed from the datastore and therefore we would send > vast numbers of SimpleProgress messages referring to blocks we have already > downloaded. I'm not sure I understand this. Does this mean that now a client does not receive at all SimpleProgress for "old" (resumed) inserts? > This should be dependant on a Verbosity flag. Right, I can look into doing this, when the vulnerability issue is clarified. > Also, your diff is empty. This might be a kmail problem on my end though... . . . What about Florent concerns? I didn't think of that when preparing the patch. If this is a problem, I guess freemulet ad-hoc solution will suffer from the same vulnerability.
