On Wed, Jul 09, 2008 at 05:35:46AM -0700, Jeff Johnson wrote: >2) From a fundamental coding design POV, adding --rsyncable to rpmio >code is just >plain wrong. That's as true for the patched internal zlib as it is >for your gzdio >patches. The issue of when gzflush() is called is fundamentally a >compression >and rsync transport, not a *.rpm payload packaging, issue. > >So isn't a pure API/ABI drop-in replacement for gzio(3), with a >"gzwrite" rather >than a "rsyncable_gzwrite" symbol a better approach? There are many >applications, >not just rpm, that _MUST_ participate in an efficient *.rpm >distribution framework, >so patching gzdio in rpmio is just a tiny piece of a much bigger >puzzle, where "gzwrite" >rather than "rsyncable_gzwrite" is likelier to be successful. JMHO, >YMMV, as always.
Hmm. Let me argue here just a bit. You're saying that indirect gzflush() calls are somewhat alien to plain gzdio abstrcation. However, from gzFile higher-level (logical) perspective, calling gzflush() is also simply a no-op. The worst thing that can ever happen is calling gzflush() too often, which can degrade compression. Now, rsyncable_gzwrite is simply about calling real gzwrite+gzflush in a loop. Provided that pointer arithmetic in rsyncable_gzwrite(), is valid, gzflush is still a no-op, and gzdio abstraction is preserved, and nothing bad can ever happen. The rest of the code is sync_hint(), which is about finding the right sync points, and also, basically, not calling gzflush() too often. So, the code may look weired, but the idea is simple. I introdice rsyncable_gzwrite, which is equivalent to gzwrite from the higher-level (logical) point of view. There is no possiblity for rsyncable_gzwrite to produce logically invalid output. The rest of the code is just a hint for rsyncable_gzwrite() loop. BTW, we can have something like %_rsyncable_gzwrite macro, to switch between plain gzwrite and rsyncable_gzwrite.
pgpzqa7EJS54H.pgp
Description: PGP signature
