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

Set client key when activating clients in frontend #373

Open
window9u opened this issue Oct 19, 2024 · 0 comments
Open

Set client key when activating clients in frontend #373

window9u opened this issue Oct 19, 2024 · 0 comments
Labels
enhancement 🌟 New feature or request

Comments

@window9u
Copy link

window9u commented Oct 19, 2024

What would you like to be added:
Currently, when activating a client in the Codepair frontend, we don't specify a key for the client. This leads to the creation of a new client each time using Yorkie. If a key is not provided, a random client key is automatically generated.

I propose adding an option in the Codepair frontend to allow users to set their own keys as UUIDs during the activation process. This can be implemented using the key option in the ClientOptions interface (link).

Why is this needed:
This enhancement could have several benefits:

  • Prevention of repeated client creations: Users would avoid the need to create new clients every time, helping in better resource management.
  • Reduction of server-side additional work: By leveraging unique values already managed in Codepair, fewer additional tasks will be needed on the server side.
  • Enhanced functionalities in document edits: By utilizing the actor ID, we could introduce features that visually identify contributions based on the actor's color.
    • Client ID visibility: This would enable easy retrieval of the client ID, thus improving document ownership and change actor identification.
    • Semantic search: Particularly when implementing features like semantic search to identify document authors.

Current Scenario (as-is):

Currently, a single user can connect simultaneously to a document as if they are multiple users.

Proposed Scenario (to-be):
Implementing this feature would likely restrict a single user to one active connection per document, improving the integrity of document edits and user sessions. link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 🌟 New feature or request
Projects
Status: Backlog
Status: Backlog
Development

No branches or pull requests

1 participant