IHttpRequestIdentifierFeature using Guid vs string

[avanderhoorn]

Just wondering why IHttpRequestIdentifierFeature had its Identifier changed from a Guid to a string. This means that we can't just take this identifier and use it for storing/grouping the data. We will have to generate our own guid and then keep this around as well for correlation sake with other systems. I can see that the decision was made in #310 but it doesn't go into the why.

// @Tratcher @davidfowl @SergeyKanzhelev

[davidfowl]

This means that we can't just take this identifier and use it for storing/grouping the data.

How did you come to that conclusion?

[avanderhoorn]

Well most storage mechanisms have the concept that a Guid is fairly unique and has bounded "constraints" (i.e. its not 10,000 chars long), who knows that the string will contain.

[avanderhoorn]

Even though this is designed for logging identifiers rather than correlation across systems, I could still imagine that a use might want to correlate between Glimpse and a log file they have.

[sporty81]

Well for APM type products that inspect variables, I think it is a lot easier to get the value of a string than a guid.

[SergeyKanzhelev]

In Application Insights all identifier are strings. So we should be good here.

We have two types of user identity - anonymous user and authenticated user. Anonymous user is typically a Guid.NewGuid().ToString(). We use it mostly for filtering and correlation. For authenticated users we recommend to use human-readable strings as we think to use it for usage scenarios.

[avanderhoorn]

Ok sounds good.