search

iot-social-network-link / meetalk

1 stars 0 forks source link

【必須】roomステータス管理 #12

Closed matsu0228 closed 8 years ago

matsu0228 commented 8 years ago

試験して気づいたこと。

現状の仕様だと、性別に偏りがある場合に、永遠に合コンできない ・roomのステータス管理(長時間使用されていない部屋の破棄）ができていない ・性別ごとに最小indexのroomに入手する →男:index=100、女:index=2のような状況が生じるため、永遠に合コンできなくなっていまう。

対応案） ・作成されたが合コンが始まらないroomは、一定時間（例：15分）たったら破棄する

matsu0228 commented 8 years ago

・退出したユーザがいたら、クライアントからサーバへ、delete_userAPIをリクエスト

delete_userAPI
HTTP Method: Delete
Argument: window_id, room_id
Return: true / false

サーバ側処理内容
1.当該のwidをもつユーザが所属しているroomの男女数を更新
2.当該のwidをもつユーザのレコード削除
hirokoji commented 8 years ago

依頼いただいたAPI実装しました。確認お願いします。

男女比に偏りがあった場合に 合コンできない問題の解決策は、、、合コン待ち人数をトップページに記述するとか？ 機能どうこうというよりかはこのサービスの根本的な難しさだね。。。

matsu0228 commented 8 years ago

@hiro: deleteAPI実装ありがとー！

サーバ側処理内容 1.当該のwidをもつユーザが所属しているroomの男女数を更新 2.当該のwidをもつユーザのレコード削除

2の方実装してもらったと思うので、後でいいので1の機能も実装お願いします！ 例：widに該当するユーザーが男なら、そのユーザーが所属するルームの男の人数を1減らす

matsu0228 commented 8 years ago

仕様案

1)満室前の場合 1-1.退室ボタンを押したユーザは、画面から「ビデオ枠」「名前」「性別」を非表示にする 1-2.人数を補充する。具体的には、退室ボタンを押したユーザ枠分、あとからユーザが入れるようにする。 　例：男が退室したら、もう一人男が入れる 1-3.ブラウザごと終了した場合の処理は、要検討 1-4.画面更新など、実際には退室していないが、skyway側で退出扱い(peerが切れた場合)は、要検討

2)満室後の場合 2-1.退室ボタンを押したユーザは、画面から「ビデオ枠」「名前」「性別」を非表示にする 2-2.人数を補充しない。　例：満室後に男が退室しても、他のユーザは入れない

残タスク

1-1.2-1. →deleteAPIにて実装済み

1-2.2-2. →未実装。担当：ヒロ →deleteAPIがリクエストされたタイミングで、サーバ側の処理の追加が必要

1-3.1-4. →要検討。担当：松木 →skayway側のユーザ管理の仕様を調査する →1-3の課題は、他ユーザ退室時(skywayからのcallback)に、deleteAPIをリクエストするようにすれば解決可能だが、 　1-4の場合に過剰に削除してしまう

ykubot commented 8 years ago

modelの設計変えようか。 今はvote画面でroom idに紐づくユーザを検索してるけど、それだと一度roomに入って抜けたときに削除する処理が必要になる。 人数決まってるならroomモデルでユーザを管理した方が良い気がする。

もう一つ理由があって、ユーザのアクティベーションを後で取りたいんだよね。 そうするとroomでユーザ管理した方が後々便利。

xkumiyu commented 8 years ago

userモデルとroomモデルにstatusを追加

xkumiyu commented 8 years ago

APIにroomから退出したときの処理を追加