On Fri, Apr 01, 2011 at 09:05:59AM -0400, Roy Smith wrote: > > On Thu, Mar 31, 2011 at 08:10:04AM -0400, Roy Smith wrote: > >> I didn't really write a specification, but I think a critical part of the > >> spec > >> would be that the only guarantee about the id string is that it's unique > > > > It's unique within a delimited perimeter. > > Well, yes, but that's a general problem which is difficult to solve.
Solving it for every use is indeed very difficult. Solving it on a case-by-case basis is a lot easier (and indeed, you did it for your case). > There's really only two ways to generate unique identifiers. One is to use > some probabilistic algorithm with a large enough entropy that the chances of > a collision are very low. Uuid, and crypto hashes of various flavors are all > examples of this approach. > > The other is to have some globally administered namespace. Examples would be > global IPv6 addresses (and IPv4, before evil things like NAT came along!), > telephone numbers, and the like. Even so, those are only useful for > cooperating parties, not Exactly, and many people will rely on this principle with what is unique in their case. > > providing proofs in case of litigation > > since they can be spoofed by evil-doers. Not always, it depends where/how the logs are produced. > I understand that other people may have other uses for this capability, which > would imply additional requirements. I'm fine with switching to a different > way of generating the unique ids. My concerns are three: > > 1) Efficiency. Computing a UUID on every request, for example, would > probably be prohibitively expensive. > > 2) Portability. I only have a very limited number of systems available to me > at the moment (Ubuntu and OSX). As things get more complex (i.e. involving > crypto), they also get less portable, and I have no way to test my code on > other systems. > > 3) My time. I have a limited amount of time I can devote to this activity. > I'm certainly willing to invest more time than I have if I can make this more > useful to a wider audience. We find haproxy a useful tool in our business > and giving back something to the community is an obligation I take seriously. > On the other hand, I don't want to get dragged down a rat-hole implementing > every conceivable bell and whistle. > > So, with the above three points in mind, what's a reasonable path to continue > this and get it to a point where it's worth including in the core > distribution? As I said in the earlier discussion some months ago, I already have customers who heavily rely on this feature with specific formats that will not change but will have to evolve. Their use cases won't necessarily match other people's, just as well as your use case will not match their requirements. So my goal is to do something heavily configurable in order to define a format for this header, which would be comparable to an sprintf() string or to apache's customlog. That would fit your usage and the ones that I already know about, and would easily be extensible to any other needs. I'm well aware this can take some time. We had already planned to work on it at Exceliance because some of our customers would also like to get this. I can accept an intermediate solution, but I don't want to merge anything that will make it harder to maintain in the long term. And in general, everything we do one simple way is much harder to deal with when we try to implement a more generic method. Regards, Willy
