On Thu, Oct 21, 2010 at 10:57:51AM +0200, Michael Schroeder wrote: > On Tue, Oct 19, 2010 at 05:54:17PM +0200, Peter Pöml wrote: > > Oh, there is no reason to not touch the current zsync support - it is > > experimental, documented as such, and not configured by default. IMO it > > is better to improve it and make it more flexible, than to add a second > > implementation which is even less flexible, and duplicates code. It also > > duplicates data in the database, and CPU time in calculating the hashes. > > Especially the code maintenance aspect would give me a headache. It's > > not as if this project had too much manpower ;-) > > The difference is that mirrorbrain's zsync support is written with > the goal to deliver a "zsync" file. I just need the extra info in > the metalink. Fine, but then you just need to use the data that's already there and include it in the Metalink, that's all. No need for duplicated code for generation of the hashes, or another database column. > > > Btw, you really should put the hash type of the pieces in the database > > > and not assume that sha-1 is always used. > > > > I disagree here. The database columns for piecewise hashes are clearly > > named "sha1pieces" and "sha1piecesize" which makes sure that there is no > > misunderstanding. One doesn't need to fill them or use them, of course. > > That's ok with me. I just wanted to point out that you'll need to > modify the database layout for every new hash type that you'll > want to support. Okay, it just sounded as if you have strong reasons to recommend something different. Database columns are cheap - sophisticated code to deal with microformats is expensive. > > > Only if you use mirrorbrain's zsync support, which I don't. > > > > If there are other reasons not to use it, except fear of breaking > > it, could you explain them? Maybe there is something that I miss. > > I don't need it, as I don't run zsync. I do metalink downloads > with the additional feature to not download blocks that are > already there. For this I need a single part of the zsync file, > the "rsums". The rsums are already stored in the database, and you might consider simply using them, instead of generating additional rsums and piggybacking them into another column. I can definitely not accept a patch that duplicates that stuff, I'm sorry. [...] > Oh, of course. I didn't say that you should integrate that patch > (as it is a hack). I just sent it to you so that you know what > we currently use. Okay, I was lead into thinking that you contacted me in order to integrate your work upstream. Probably because I get so few patches ;-) You are welcome if you want to pursue it later. And thanks for keeping me in the loop. Peter _______________________________________________ mirrorbrain mailing list Archive: http://mirrorbrain.org/archive/mirrorbrain/ Note: To remove yourself from this mailing list, send a mail with the content unsubscribe to the address mirrorbrain-request_at_mirrorbrain.orgReceived on Thu Oct 21 2010 - 11:58:32 GMT
This archive was generated by hypermail 2.3.0 : Thu Oct 21 2010 - 12:32:09 GMT