Re: [mirrorbrain] Re: Repository delta download und Mirrorbrain 2.13

From: Peter Pöml <peter_at_poeml.de>
Date: Thu, 21 Oct 2010 13:58:29 +0200
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.org
Received 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