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
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
keyoption in the ClientOptions interface (link).Why is this needed: This enhancement could have several benefits:
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