On 2/14/06, Jake McGuire <[EMAIL PROTECTED]> wrote: > Summary: Why not aim higher? Protocol changes happen infrequently, > or at least they should, so if we can stick in some other stuff that > we think is going to be useful down the road.
I want this out the door quickly, so I'm trying to do the smallest possible perturbation of the protocol. > Details: Why use a binary encoding? Because that's how distcc is written, and it's easy. > Network traffic at this point is > pretty cheap, especially one-way data, as is the minor amount of CPU > time to process some text. Bitfields just add the potential for > endian screwups and make some sorts of processing more complicated. The bitfield in question is encoded in hex, and is endian-safe, I think. (Have *you* read the distcc protocol spec?) > How about: > > Commands starting with '?' are optional, and require ack/nack. Like ? > HSH for hashed source code. > > Commands starting with '+' are optional and should be silently > ignored if not supported. Like, say, if someone wanted to make > distccd report statistics like cache hits, or wanted distcc to flush > the object cache a) I use HTTP for reporting statistics b) I'm not likely to allow flushing the cache via the network until there's some security in place; until then, it's safe to just blow away the contents of the cache directory while distcc is running, at least with my implementation. > Also... not sure what your build traffic looks like, but it's > probably worthwhile to put a placeholder in the cache when > compilation starts so that if there's a "hit" it only gets compiled > once. Not sure what you mean. But during benchmarking of simultaneous builds on a cold cache, we got better performance if we noticed simultaneous compile requests for the same source and handled them nicely, so we do that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
