-
-
Notifications
You must be signed in to change notification settings - Fork 37
[Platform] Use JSON Path to convert responses #136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
ed6eaea
to
7ec4f22
Compare
I really like the idea! Know that if you manage to get a resource for the response, JsonPath uses JsonStreamer to optimize the part to actually decode. Just in case 🙂 Given that JsonPath is experimental, I'd suggest changing the composer constraint to 7.3.*. That's what we do in core because experimental components may not be compatible between their minor versions. I have no plan to change classes or signatures in the JsonPath component until it's stable release as I managed to make it RFC compliant lately with the exact same API. But better be safe than sorry! |
Interesting approach! Do we even need the platform-specific EDIT: ok hmm I guess the idea was to encapsulate the "protocol" in the converter to be reused in different platforms |
8b26c09
to
4387b79
Compare
Thanks for that!
exactly |
4387b79
to
b820262
Compare
We just created some Thanks |
b820262
to
e72b08c
Compare
This is the first draft of one idea to encapsulate the way json response are converted into DTOs using the new JSON Path component - in combination with using the
Capability::OUTPUT_VECTOR
to activate a centralized converter with low priority - see google example where a specific one still gets activated first.In general the idea would be to define different, response type specific extractors, that can be re-used across bridges, configured or exchanged with custom ones. The embedding responses are def the easiest ones here, but work to get an idea of the concept - i hope. The goal would be to get rid off the ResponseConverter duplicates and on top have a centralized standard that works basically with the OpenAI contract - with the perspective of enabling more compatible platform/models out of the box, see #114
The weak spot here would be the centralization in combination with the capability check - but there are ways to solve that I guess.
WDYT?