Use case

[kkweon]

payload는 프론트엔드에 따라 evolve 시켜나갈 수 있도록 시작은

user: string message: string

와 같이 reasonable 한 아무 값

[kkweon]

• when a user joins the session, it broadcasts to all users that the user joined the session
• when a user joins the session, it receives the current snapshot(history) of the session
• when a user sends a message, it broadcasts to all users except the sender

[nicewook]

My proposal on first sight

• If connect without RoomID then make new Room. or join the connection with RoomID
• Connection should provide Username to the server. POST?
• ChatRoom command
  • /url: ChatRoom joining link
  • /list: List all the ChatRooms

[nicewook]

Endpoint proposal

/: List all the ChatRoom URL to join OR make new ChatRoom URL /ws: Make a new ChatRoom /ws/{roomID}: Join the ChatRoom of RoomID. if there is no ChatRoom of the RoomID it will be created

[kkweon]

/ws 하나만 있는게 좋을 것 같은데 일단 제안주신대로 좋습니다. 직접 구현하면서 보는게 좋겠습니다.

[nicewook]

/ws에 POST 아무것도 없으면 새로 만들고, post내에 room id와 username이 있으면 그걸 쓰고 이렇게 해도 되겠군요.

[nicewook]

저렇게 하면 좋겠다 수준은 아니고 그냥 일단 생각나는 대로 던져둔 것이다보니 더 좋은게 있으시면 이야기주십시오

[kkweon]

지금은 제가 보기엔 일반적인 웹소켓이 아니라 그냥 HTTP Request/Response 식으로 생각하신것으로 생각됩니다.

websocket 커넥션이 연결 되고 나서

join-room event 가 갑니다.

event name: 'join-room' event data: { username, sessionID }

그럼 이걸

같은 세션ID를 가진 소켓에 broadcast 해주시면 되겠습니다.

[kkweon]

정확한 payload 에 대한 타입 특히 메시지 타입은 evolve 해야 되니 그냥 예시로 봐주세요.

[nicewook]

1. type 이해했습니다.
2. 저는 roomID라 생각했었는데 이런 경우에 sessionID라고 표현하는 것이 더욱 업계 일반적일까요? (마이너한 질문입니다)

[nicewook]

이 시나리오에서 하나 이해가 되지 않는게 새로운 chatroom 들어가는 것과 기존 chatroom의 리스트를 얻는 부분에 대한 구현고민이 일단은 생략된 것이지요?

그게 아니라면 new 또는 현재 존재하는 chatroom list를 Server가 Client에게 connection 직후에 보내줘야 할 듯 싶습니다

[kkweon]

채팅서버랑 만드는게 설계가 같다는 얘기고 채팅서버를 만드는게 아닙니다.

plantumllive 를 만드는 건데요

list 는 방장에 의해 링크 공유받는 식으로 알 필요 없습니다.

[kkweon]

그래서 타입도 참고용인 이유구요.

실제 자료구조는 Rope 와 CRDT 혹은 OT 가 될 예정입니다.

• https://en.wikipedia.org/wiki/Rope_(data_structure)
• https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
• https://en.wikipedia.org/wiki/Operational_transformation

[nicewook]

제가 전체 그림을 보지 않고 만들어서 헷갈리는 측면이 있나 봅니다. plantuml을 여러명이 동시에 작업할 수 있게 하는게 목표라고 보면 되는 것이겠지요?

1. 그렇다면 A그룹, B그룹이 이와 같은 작업을 한다면 각 그룹별 작업공간, 즉 일종의 chatroom이 필요한 게 아닌가요?
2. 방장이 새로운 작업공간을 만들면 그 공간에 sessionID를 받고 그걸 (예를 들어) 슬랙으로 공유해서 함께 작업한다고 보면 되겠지요? 이후에도 이 작업공간의 주소만 기억하면 다시 들어가서 이어서 작업이 가능하겠구요. 그러려면 작업공간 주소(==sessonid)를 key로 하여 저장을 하여야겠네요
3. 말씀하시는 Rope & CRDT 또는 OT가 message 안에 들어간다고 보면 될까요? 아닐 것도 같은데 Websocket의 입장에서는 이 자료구조를 어디에 쓰게 되는 것인지 감이 잘 오지 않습니다.

예를 들면 message에 이 자료구조로 된 값들이 오갈 것인데 그건 Websocket은 몰라도 된다. 그냥 []byte로 온거 []byte로 전달해주면 된다는 걸까요? 아니면?

[nicewook]

Rope, CRDT, OT 한번 들여다 봐야겠네요. 감사합니다

[kkweon]

1. 필요합니다. listing 은 필요 없습니다.
2. 네, websocket 은 mediator 일뿐 primary key에 따라 전달하는 역할만 합니다.
3. 네. websocket 은 사용하지 않습니다. 자료 받아서 저장하고 전달하기만 하면 됩니다.