-
Notifications
You must be signed in to change notification settings - Fork 21
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
Add a chat-identifier endpoint #339
Comments
I don't really understand what the issue is with the current approach. ragna/ragna/deploy/_api/core.py Lines 203 to 206 in c1c159d
If you know the ID upfront, you can also just get the data of this particular chat with ragna/ragna/deploy/_api/core.py Lines 208 to 211 in c1c159d
How does the number of users play into this? Both endpoints listed above are user-specific. |
It gives all the messages, sources etc for all chats. The size of this object that is sent over the network grows over time and also requires a bunch of logic on the consumer side for extracting chat IDs and chat names.
That's the point of this PR - how can I know the ID (for a conversation that I created in a previous session)? I have to hit the
I confused things here, apologies. There is the performance of the UI (see previous comments) and the performance of the API: If we have a central service hosting the API, then the API will need to load a user's entire chat history into memory just to get the names of previous chats. For a large number of users, this can create unnecessary load. Although I now realise that #338 doesn't actually address this API issue, only the UI issue. Ultimately, it's a QoL feature request. It's possible to get the behaviour I want with a GET to |
Could you clarify the use case you have? Why do you need only this information rather than what is returned by |
See my initial message.
|
Here is how we are currently doing it in our UI:
@nenb IIUC, here is what you want to do instead:
Compared to our method this has the upside that on startup we only need to load the data we actually require and thus can be quite a bit faster if there are multiple chats with a ton of messages. However, now we need to hit Is that an accurate description of what you want to do? |
More or less. There is a branch here. I'm not sure if it will be particularly helpful, as it has lots of changes, but the idea is that actions in the left sidebar drive the rest of the UI.
My experience so far is that this is negligible compared to the time taken to actually rebuild and display the chat messages when switching between chats (which also affects the current version). Here is a screenshot if what the branch currently looks like: |
In that case I'm confused again. In #339 (comment) you wrote
I assumed the "issue" you are referencing here is performance. If that is not the problem, could you elaborate what the issue actually is? |
I'm not sure if I have any more to add to this discussion (but I am still happy to open a PR if you are willing to consider the addition). I'll add an earlier message I posted here again as I think it best summarises the situation:
|
What do you mean by "quite different"? The chat content is exactly the same. From #339 (comment)
Unless I'm missing something, there is no QoL improvement here. |
Feature description
I would like to propose a new API endpoint that will only return a list of previous chat IDs. More specifically, the endpoint would return a list of mappings from chat ID to chat name for a user.
Value and/or benefit
This is useful functionality for interacting with specific historical chats. For example, if I would like to only show messages from a certain chat. Currently, it's necessary to retrieve all information about all chats to get this sort of information. This can become an issue for UI development when there are lots of users/users with a large amount of chats.
Anything else?
I have proposed an example in #338
The text was updated successfully, but these errors were encountered: