Skip to content
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

bridge: UI model #85

Open
mgood opened this issue Feb 2, 2024 · 2 comments
Open

bridge: UI model #85

mgood opened this issue Feb 2, 2024 · 2 comments
Assignees

Comments

@mgood
Copy link
Collaborator

mgood commented Feb 2, 2024

(split from #63)

Even though there is a "view model" setup on the Go side, we're also setting one up client side in JavaScript. This can be used to process session event data into more iterable timeline events. However, eventually we'll probably want to do most of this server side so a text "transcript" of the session can be easily passed into other agents/services.

Fine-grained events need to be grouped together into a bigger logical chunk for display. This is currently happening client-side in JavaScript, but there may be advantages to doing more of that pre-processing on the backend. This could simplify the JavaScript client, and allow for other clients that want a higher-level view of the data to use that instead.

There's also a question of how to send data to the client. We're currently serializing the full session on each update. This could become large for long-running sessions, so we could consider whether to switch to sending just the event updates instead.

@mgood mgood self-assigned this Feb 2, 2024
@progrium
Copy link
Collaborator

progrium commented Feb 2, 2024

Right now there is a "View" on the backend that includes more than just the session (right now just the list of other sessions) so the backend will have at least an initial view model it sends to the frontend, but i think most of the translation of events into logical chunks of messages and timeline events could still be done on the frontend. This would also make it easier to just push session events to the frontend after an initial sync.

There is a similar chunking thing that has to happen on the backend for producing a text "transcript" used for working with LLMs, but that could be done totally separately. Going to make an issue for that.

@mgood
Copy link
Collaborator Author

mgood commented Feb 2, 2024

Yeah, keeping the chunking on the client does make it simpler to send each event as an update after the initial load.
I guess one option for chunking on the backend would be to make that its own event. So you'd have an agent that listens for transcription events, and can generate a new chunked text event or update an existing chunk to add that content.
Though I'm not sure that's necessary. Like you said, the transcripts for LLMs might be different enough anyway that it makes sense to keep the logic separate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants