>From: "Jeff Johnson" <n3npq@mac.com>
>To: <rpm-devel@rpm5.org>
>Date: July 09, 2008 06:17:34 PM EDT
>Subject: Re: rsyncable gzdio
>
>
>On Jul 9, 2008, at 8:35 AM, Jeff Johnson wrote:
>
>>
>>> From: "Jeff Johnson" <n3npq@mac.com>
>>> To: <rpm-devel@rpm5.org>
>>> Date: July 09, 2008 08:02:41 AM EDT
>>> Subject: Re: rsyncable gzdio
>>>
>>> Grrr, my 4th attempt at a reply without delivery ...
>>>
>>> On Jul 8, 2008, at 6:57 PM, Alexey Tourbin wrote:
>>>
>>>> On Mon, Jul 07, 2008 at 11:44:07PM +0200, Jeff Johnson wrote:
>>>>>     - make gzdio.c standalone.
>>>>
>>>> BTW, I have rsyncable gzdio implemntation (this does not require
>>>> patched zlib, one only has to call gzflush() at certain sync  
>>>> points).
>>>>
>>>
>>> I'd like to not carry internal zlib.
>>>
>>> You are absolutely correct that the --rsyncable issue is calling
>>> gzflush() at
>>> certain sync points.
>>>
>>>> It is known to work well.  Please review the patches and tell me
>>>> whether you want it or not.
>>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>>> a=commitdiff;h=c761902b
>>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>>> a=commitdiff;h=f7b5ee1e
>>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>>> a=commitdiff;h=8d5e355e
>>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>>> a=commitdiff;h=52b2499a
>>>
>>>
>>> In summary, your patches are quite nicely done and extremely clever,
>>> but I'm not
>>> sure that RPMIO could/should use them, as I've tried to describe  
>>> above.
>>>
>>> I'm most certainly willing to be convinced otherwise however.
>>>
>
>(aside) Apologies for possibly sounding waspish, but MobileMe deployment
>as well as wrestling with neon transport is, well, more b0rkage than  
>I can stand
>in a single day.
>
>I personally think I'm going to have to reimplement all of the  
>compressors
>as lightweight buffer compress/decompress methods that can be attached
>to any RPMIO output as side effect, I see no other way forward atm.
>
>So my concern about supporting your patches in "production" gzdio is
>likely m00t.
>
>So let's see if your patches work on HEAD. I've got your 1st patch  
>ready to check-in,
>feel free to check-in the others (or be lazy and wait for me ;-).
>
>(aside) Also, please feel free to alter my check-in stylistically  
>too. I have certain
>fetishes, always preferring
>     typedef struct foo_s * foo
>over
>     typedef struct foo_s foo;
>
>I also tend to do
>     p = _free(p);
>rather than the simpler/cleaner
>     free(p);
>mostly because I've burned myself by refactoring (and forgetting
>the error msg usage of p, which then points to already free'd memory)
>that I tend to burn my pointers routinely.
>
>But both of the above changes are just my fetishes ...
>
>I can live with most anything written in C, the above is what I do  
>(and why).
>
>Nice & clever patches is mho still. The cpio tracking may have to be  
>generalized
>to tar, but perhaps not. What I really want to see is the bandwidth  
>improvement,
>I'm obligated to try to make *.rpm packages rsyncable even if no one  
>has a clue,
>but have not been able to interest anyone else in the savings for years.
>
>73 de Jeff
>
>
>
>