Accept: application/llm#5962
Conversation
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
|
This is neat. Is the usage of |
Signed-off-by: Joe Elliott <number101010@gmail.com>
No strong feelings. I liked this b/c I expect it to change in the future and this felt fluid and easy, but certainly actual structs would would be easier to read and test. Let me put that together. Edit: There is one place that needs to remain simplified jsonotel json |
Signed-off-by: Joe Elliott <number101010@gmail.com>
|
LGTM, the new accept content type makes this easy to support in the future, and understand that some looseness in the response here is totally fine (preferable even). But defer on the specific header value - if there is a growing spec and recommended value, it makes sense to adopt it. But as long as existing callers (i.e. Grafana Assistant) can send it, it should be fine. |
Signed-off-by: Joe Elliott <number101010@gmail.com>
What this PR does:
Adds support to 2 endpoints for a new Accept header value:
application/llm. This is a request for a response that is LLM friendly. After discussions with internal experts, Claude and Gemini the PR'ed format was chosen: a simplified json representation of the trace.This representation is subject to change and should not be relied on. It is intended for LLM consumption only. Even a fundamental change to its representation (yaml? markdown?) would not be considered breaking.
Other changes:
application/llmas the header.Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]