Could 'HTTP' be removed from the name?
There is nothing special about HTTP in the TextFormat and it could be used in any UTF8 string protocol.
I think the intention here was to communicate the constraint that keys are valid HTTP header names and that entries follow HTTP header semantics. Format and semantics should be documented sufficiently in the spec, however, so removing the HTTP prefix should be fine.
@arminru I think the question is not whether http formatter may be used for any other text protocol. It's other way around - will we need a separate text formatter that will work more efficiently as it doesn't impose the need to limit charset as http does
I'd suggest to keep a vote - if you have a protocol in mind that needs to have text formatter - please comment here.
Please comment on this if you still think want to change the name.
Think I agree with @lmolkova in this instance. If the HTTP part of the name indicates restrictions on character set, that is not clear in the name at all. I also interpreted this to mean "this is specifically to be used with http" and I assume I am not the only one.
I just ran into this also. It feels weird to use a class named HttpTextFormat to inject headers into Kafka messages.
@carlosalberto I vote to remove the HTTP from the name. Can we do that?
I support this. I believe the original question was whether all the http-specific encoding will also needs to be applied to general text format that might support unicode. I believe the conclusion of the discussion https://github.com/w3c/trace-context/issues/360 was that we better have consistent limited charsets than errors from conversions back and forth. Even thouh it is not documented in trace context spec, I would suggest to get rid of http prefix proactively.
@bogdandrutu I'm fine with it. I can cook a PR for this.
Most helpful comment
I just ran into this also. It feels weird to use a class named
HttpTextFormatto inject headers into Kafka messages.