Okay - here's a thought. Why not do what the original message asked?
Checkout their changes and look at what they did.
Then we can have the discussion about how intrusive it is. Otherwise,
all we're doing is debating what they -might- have done, or what
someone thinks they -should- have don
The point here is very different, and is not being made because of objections
for
fail-over support. Previous work took precisely this sort of approach, and in
that
particular case the desire to support reliability, but be able to compile out
this
support still had a negative performance imp
The objections being cited are somewhat unfair - perhaps people do not
understand the proposal being made? The developers have gone out of
their way to ensure that all changes are configured out unless you
specifically select to use that functionality. This has been our
policy from day one
On 8/2/09 12:55 AM, "Brian Barrett" wrote:
While I agree that performance impact (latency in this case) is
important, I disagree that this necessarily belongs somewhere other
than ob1. For example, a zero-performance impact solution would be to
provide two versions of all the interface functi
While I agree that performance impact (latency in this case) is
important, I disagree that this necessarily belongs somewhere other
than ob1. For example, a zero-performance impact solution would be to
provide two versions of all the interface functions, one with failover
turned on and one