マウスイベントの対応依頼とパーミッションに関する仕様の提案

[shunya murata]

murataです．

マウスイベントの実装にむけて，
サーバを通してのテストをおこないたいので，
マウスイベントの対応をお願いします．
通信データについてはwikiに書いたので，そちらを参照してください．

あと，もうひとつとして，
そろそろパーミッションに関する仕様を決めないとなので，
自分で考えたものを書いておきます．

何かつっこみや追加事項があればお願いします．
特にサーバ側の都合はわからないので，お願いします．

以下提案仕様
1.ルーム作成時
    ・新規ルーム作成時のみダイアログが出て，次の設定を決められるように
        パスワード
        デフォルトのパーミッション
            いくつかセットを用意(手動設定もできるように)
    ・マスター権限
        ルーム作成者が自動的に持つ
        マスター権限を有する者は以下の権限を持つ
            すべての操作権限
            他の人のパーミッションを変更する権限
        マスター権限は譲渡可能
            複数マスターが存在することも可能（一応今後も考え内部的な仕様として
            いなくなったら，入室が若い順に自動的に譲渡される

2.権限変更
    ・一人単位で設定
        すべての権限有効，すべての権限無効，デフォルト設定のどれかに設定できる
        （内部的には各アクションごとに設定可能に
    ・UIは，サイドバーのユーザリストを選択した際にサイドバーに3つのボタンに表示
    ・マスター権限の譲渡はコマンド(Ctrl押しながら選択とか)で可能

3.通信情報
    [送信]
        ルーム作成時
            ・パスワード
            ・デフォルトのパーミッション
        権限変更時
            ・変更するUserのID
            ・変更後のパーミッションセット
    [受信]
        ルーム作成時
            ・ルームが作成できたかを変えす
            ・新規ルーム設定ダイアログが出て，設定を送信したときに，
              すでに作成されていた場合は，作成エラーを返して，ログインしないように
        サインイン時
            ・自分のパーミッション
            ・メンバーリスト
        権限変更時
            ・自分のパーミッション
       
    パーミッションの内容は
    EV_TAB_LOCATION     0x01
    EV_TAB_CLOSE        0x02
    EV_SCROLL_SHIFT     0x04
    EV_USER_PERMISSION  0x08
    EV_SELECT_RANGE     0x10
    EV_KEY_ACT          0x11
    EV_MOUSE_ACT        0x12
    として，各ビットを立てた数値を送受信する

[murata]

murataです。

新規ルーム生成時の設定項目に
以下の要素が抜けていたので追加しときます
・匿名ログインの許可 ON or　OFF

[shunya murata]

murataです。

あまり時間がないのと、反応がないので、
こちらで仕様決めときます。

以下の仕様で作り始めるので、
サーバ側はこちらに合わせてください。

API: room/join.xml(既存の変更)
ルームに参加リクエストを投げる
指定したルームがまだ作成されていない場合は、サインインせず、createdをfalseにして返す
指定したルームが作成されている場合、サインインし、createdをtrueにして返し、nameとroom_idを返す
入力
name: ルーム名
password: ルームのパスワード　パスワード制限がないルームの場合は無視
出力
room.@created: 指定するルームすでに作成済み true 作成していない場合 false
room.@name: 入室するルームの名前
room.@room_id: 入室するルームのID

API: room/create.xml(新規)
ルームを作成する
指定したルームが作成できない場合は、createをfalseにして返す
作成できた場合は、createをtrueにして返す
入力
name: ルーム名
password: ルームのパスワード　入っていない場合はパスワード制限なし
perm: そのルームのデフォルトのパーミッション。ルームに参加したら最初はこのパーミッションになる

anony: 匿名ログインを許可 true 不許可 false
出力
room.@create: ルーム作成成功 true 失敗 false
room.@name: ルーム名
room.@room_id: ルームのID

2008/12/01 20:08 murata <shy.m...@gmail.com>:

[shunya murata]

ミスって途中で送ってしまったので続きを

API: actionlogs/lists.xml(既存の変更)
これは全部の仕様を書くのは面倒なので変更点のみ
入力のl=0の時のみ以下の２つをアクションとして返す

actionId: 304 (EV_USER_LIST)
paramの内容は
kをuser_id、vをそのidのユーザ名として
ユーザのリストを返す

actionId: 305 (EV_USER_PERMISSION)
paramの内容は
permission(perm) そのユーザのパーミッション(ルームのデフォルト)

パーミッションに関しては、32ビットの整数とし、各ビットをフラグとして管理する
EV_TAB_LOCATION 0x00000001
EV_TAB_CLOSE      0x00000002
EV_SCROLL_SHIFT  0x00000004
EV_USER_PERMISSION 0x00000008
EV_SELECT_RANGE 0x00000010
EV_KEY_ACT   0x00000020
EV_MOUSE_ACT 0x00000040
とする。

また、パーミッションを変更する時があると思うので、
その際は、通常のイベントを送る処理と同じように
actionId: 305 として以下２つのパラメータを送る
permission(perm) パーミッション
user_id　ユーザID

とりあえず以上のAPIの実装されることを想定してコーディングを始めます。

あとユーザリストが間違っている場合に問い合わせをしたい時、
イベントでリクエスト(actionlogs/post.xml)を投げて、
そのリクエストを投げたユーザのみにactionlogs/lists.xmlで問い合わせたときに付加する
とかできるかな？（多分サーバ側が面倒な気がするけど・・・
面倒なら別APIにしてもらってもよいけど、どちらがいいかな？

[sotarok]

sotarokです。

とりあえず少しずつ返信。

On 12月5日, 午前1:30, "shunya murata" <shy.mur...@gmail.com> wrote:
> あとユーザリストが間違っている場合に問い合わせをしたい時、
> イベントでリクエスト(actionlogs/post.xml)を投げて、
> そのリクエストを投げたユーザのみにactionlogs/lists.xmlで問い合わせたときに付加する
> とかできるかな？（多分サーバ側が面倒な気がするけど・・・
> 面倒なら別APIにしてもらってもよいけど、どちらがいいかな？

ユーザリストが間違っているときに、post.xml にイベントを投げる必要はあるのかな？
単純に、ユーザ一覧を取得するactionをこちらで作成すればOKという話？

そしたら、rooms/userlist.xml とかにアクセスしたら、現在のユーザ一覧を返す、とかでいいかな。
パラメータは、room_id を r で渡してもらって、その部屋に自分がjoinしてたら
ユーザ一覧を取得できる、という形にしようと思います。

どうでしょう。

--
sotarok

[sotarok]

sotarokです

On 12月5日, 午前1:30, "shunya murata" <shy.mur...@gmail.com> wrote:

> actionId: 305 (EV_USER_PERMISSION)
> paramの内容は
> permission(perm) そのユーザのパーミッション(ルームのデフォルト)
>
> パーミッションに関しては、32ビットの整数とし、各ビットをフラグとして管理する
> EV_TAB_LOCATION 0x00000001
> EV_TAB_CLOSE 0x00000002
> EV_SCROLL_SHIFT 0x00000004
> EV_USER_PERMISSION 0x00000008
> EV_SELECT_RANGE 0x00000010
> EV_KEY_ACT 0x00000020
> EV_MOUSE_ACT 0x00000040
> とする。
>
> また、パーミッションを変更する時があると思うので、
> その際は、通常のイベントを送る処理と同じように
> actionId: 305 として以下２つのパラメータを送る
> permission(perm) パーミッション
> user_id ユーザID

305は，対象ユーザのPermission変更，という意味でOKですか？

それだと仮定しての話ですが，パラメータは

> permission(perm) パーミッション
> user_id ユーザID

に加えて，

・対象permを on にするのか off にするのか (true/false もしくは 1/0)

が必要かと思うのですが，いかがでしょう．


--
sotarok

[sotarok]

sotarokです

On 11月29日, 午後11:19, "shunya murata" <shy.mur...@gmail.com> wrote:
> ・マスター権限
> ルーム作成者が自動的に持つ
> マスター権限を有する者は以下の権限を持つ
> すべての操作権限
> 他の人のパーミッションを変更する権限
> マスター権限は譲渡可能
> 複数マスターが存在することも可能（一応今後も考え内部的な仕様として
> いなくなったら，入室が若い順に自動的に譲渡される

OKだと思います．

IRCにあわせて，
　OP　（オペレーター）
としてもいいですか？

OP権限てかんじで．
(似たような概念なので，使い慣れてる人にはそのほうがしっくりくるかな，と)


--
sotarok

[shunya murata]

murataです。

ユーザリストが間違っているときに、post.xml にイベントを投げる必要はあるのかな？

actionとして実装するように提案したのは、
2つ理由があって

1. 最初のユーザ取得がアクションログとの同期がとれないので、タイミングが悪いとユーザリストが更新されないことがある
2. クライアント側の実装的に通信部分は１つになって構造的によく、実装が簡単になる
ということがあるかなーと思ってます。

単純に、ユーザ一覧を取得するactionをこちらで作成すればOKという話？

 

単純にユーザ一覧取得としてactionlogに登録すると、
関係ないユーザ(すでに正常のユーザリストを所持している)も
取得してしまい、微妙かなーと思ったので、
その特定のユーザのみに取得にできないかなと。
まだユーザリストはいいけど、
パーミッション変更にも同様の処置が必要かなと思ったので、
特定ユーザのみに送信する処理があってもいいかなと。

よく考えると、全員に送っちゃって、
クライアントで必要ないアクションは無視してもよいね。
でもそれだと、現状だと自分のアクションは送られないから
結局変更を加えないとだめか。

そしたら、rooms/userlist.xml とかにアクセスしたら、現在のユーザ一覧を返す、とかでいいかな。パラメータは、room_id を r で渡してもらって、その部屋に自分がjoinしてたら
ユーザ一覧を取得できる、という形にしようと思います。

 

上記の理由により、クライアント側としては、
actionとして登録するほうが実装が楽になるのですが
サーバ側は、どんな感じでしょう？
面倒ならばrooms/userlist.xml にアクセスでもよいですが。
まぁもう一度検討お願いします。

2008/12/09 4:01 sotarok <sota...@gmail.com>:

[shunya murata]

murataです。

急いで書いたから適当な文章になってるな・・・ｗ

んと、EV_USER_PERMISSIONを利用するのは

1. ルームログイン時にデフォルトのパーミッションを取得するとき
2. OP権限(マスター権限)を持つユーザがユーザのパーミッションを変更するとき
3. パーミッションを変更されたときに、その変更を反映させるとき

クライアント側からは1と3は受信、2は送信になります。

・対象permを on にするのか off にするのか (true/false もしくは 1/0)が必要かと思うのですが，いかがでしょう．

2の時に変更後のパーミッションを送信し、
3でそのパーミッションをそのクライアントに反映する、
で問題ない気がします。
何が変更されたかは変更前のパーミッションとXORとればわかりますし。

対象permを別々に送ると通信量も増えますし、
面倒なので一気に全部ビットにして送ってしまったほうが楽な気がしますが
どうでしょう？

2008/12/09 11:19 sotarok <sota...@gmail.com>:

[shunya murata]

murataです。

あと、今回の処理をいきなりコミットすると
サーバと同期をとるまで動かなくなるので、
broadcastブランチを作成して、そっちで開発するようにしています。

なのでサーバ側もそちらで開発したほうがよいかと思います。

ちなみに、ブランチを切るとか初なので、いろいろわからないんですが
方法とか用途とか合ってます？

[Sotaro, KARASAWA]

sotarokです

2008/12/9 shunya murata <shy.m...@gmail.com>:

>> ユーザリストが間違っているときに、post.xml にイベントを投げる必要はあるのかな？
>
> actionとして実装するように提案したのは、
> 2つ理由があって
> 1. 最初のユーザ取得がアクションログとの同期がとれないので、タイミングが悪いとユーザリストが更新されないことがある
> 2. クライアント側の実装的に通信部分は１つになって構造的によく、実装が簡単になる
> ということがあるかなーと思ってます。

この，1のほうがいまいち理解ができないです．
で，この1が理解できないのでその後の話がよくわからないんで，
もうちょい具体的に説明してもらえると助かります・・・

ユーザー一覧をアクションとして登録する必要性がよくわからなくて，
つじつまが合わなくなったと判断したクライアントだけが
ユーザ一覧を取得しなおせばいいんじゃないの？と思っているのですが，
これだとなにがまずい？？

--
sotarok

[Sotaro, KARASAWA]

sotarokです


別の実装を同時に進めているわけではないので，
ブランチ切らないでturnkで動かなくなっても良いのではないかと・・・・w
サーバ側でブランチ切っても，trunk側を開発しないし，
自分の作業をマージするだけになるので意味があまり．．

とはいえ，開発環境を常にHEADにしてる人に対しては意味があるか．
一応切っておきます．

クライアント側はnaokiのJSM化とkimuraくんの
タブ周りの変更があると思うのでその間にマージ作業が発生すると
多少面倒だなーと思っていたりするのですが．
# というか実装すすんでる．．．？

マージ作業とかについては
http://www-aos.eps.s.u-tokyo.ac.jp/~takagi/SubversionMemo.html#sec29
を参考にしてください．


> ちなみに、ブランチを切るとか初なので、いろいろわからないんですが
> 方法とか用途とか合ってます？

用途とかも特に問題ないとおもいますー．
branche名はもうちょいわかりやすくしたほうがいいかもだけど．
（addon-0.2.0-broadcast とか？
　どのバージョンを目指しててなに変更してるのよってことは書いたほうがいいかな，と．）

まぁ今回は broadcast 以下にサーバも入れてしまいます．


--
sotarok


2008/12/9 shunya murata <shy.m...@gmail.com>:

[shunya murata]

murataです。

この，1のほうがいまいち理解ができないです．
で，この1が理解できないのでその後の話がよくわからないんで，
もうちょい具体的に説明してもらえると助かります・・・

これについて書く前に
現状のpost.xmlにlastActionId(l)を0で投げた時の動作について
確認なんだけど、
受信するアクションは各タブの最後に開いたページ遷移イベントのみ受信になるんだよね？
ページ遷移以外のイベント(特に入退室関連)以外も受信するようであれば
ここから書く話はスルーしちゃっておｋです。

この仕様のままで、ユーザリスト取得ＡＰＩを別に作ると
同時入室などの特定タイミングで
ユーザリストが更新されない可能性があります。

具体的には、
ユーザがルームにサインインし、ルームのメンバーリストを取得してから、
最初のイベントを取得するまでに他ユーザが入退室すると反映されないといったことが
起こる可能性があります。

よって、現状の仕様では問題があり、
これに対する解決策として、現状考えついたものは2つあって

１．
アクションログ取得の際に同時にユーザリストも取得する

２．
最初のイベントを取得する際に
入退室のログを見て、自分が入室したあとの
入退室のログを送信するするように変更する

といった方法が考えられるので、
今回簡単そうな１の手法を考えています。

それ以外の良い方法があれば、
そちらにして、実装してもらえば合わせます。

2008/12/09 23:49 Sotaro, KARASAWA <sota...@gmail.com>:

[Sotaro, KARASAWA]

sotarokです

2008/12/11 shunya murata <shy.m...@gmail.com>:
> これについて書く前に
> 現状のpost.xmlにlastActionId(l)を0で投げた時の動作について
> 確認なんだけど、
> 受信するアクションは各タブの最後に開いたページ遷移イベントのみ受信になるんだよね？

です。

で、現状の問題点と、

> １．
> アクションログ取得の際に同時にユーザリストも取得する

この解決方法でOKなんじゃないかな、というのは既に話があったのですが、
あれ？この話だったのですか？

@[mockingbird-dev:88] Re: マウスイベントの対応依頼とパーミッションに関する仕様の提案

> あとユーザリストが間違っている場合に問い合わせをしたい時、
> イベントでリクエスト(actionlogs/post.xml)を投げて、
> そのリクエストを投げたユーザのみにactionlogs/lists.xmlで問い合わせたときに付加する
> とかできるかな？（多分サーバ側が面倒な気がするけど・・・
> 面倒なら別APIにしてもらってもよいけど、どちらがいいかな？

を見ると、問い合わせ用のアクション（アクションID）を用意して、
actionlogに登録、その後listsで問い合わせたときにメンバー一覧も含めて取得
するように読めるんですが、これは俺のmisreadingだったかな？

それともこれは別の話だった？

--
sotarok

[sotarok]

sotarokです

// 権限周りとはだいぶ変わったのでトピ名変更

チャットで話してしまったので、だいたいのまとめを。
入室後のレスポンスで、ユーザリストを取得していることが原因だったので、コレをやめましょう。
ということになりました。

1. 入室時には ok or ng のステータスのみを受信
2. 最初のアクション取得時に、現在入室中のユーザの入室ログも一緒に取得
　　（現在は、入室ログなど以外の、開いているタブのページ遷移のみを取得している）
3. その他、ユーザ一覧取得用のAPIを用意

それで大体解決できそうということで。

詳細の仕様はまた。


--
sotarok


On 12月11日, 午前3:15, "Sotaro, KARASAWA" <sotar...@gmail.com> wrote:
> sotarokです
>
> 2008/12/11 shunya murata <shy.mur...@gmail.com>:

[murata]

murataです。

前に提案した仕様ですが、重要なものがぬけていたので付け足しておいてください。

> API: room/join.xml(既存の変更)
> ルームに参加リクエストを投げる
> 指定したルームがまだ作成されていない場合は、サインインせず、createdをfalseにして返す
> 指定したルームが作成されている場合、サインインし、createdをtrueにして返し、nameとroom_idを返す
> 入力
> name: ルーム名
> password: ルームのパスワード パスワード制限がないルームの場合は無視
> 出力
> room.@created: 指定するルームすでに作成済み true 作成していない場合 false
> room.@name: 入室するルームの名前
> room.@room_id: 入室するルームのID

>> 追加
room.@perm: 入室するルームのデフォルトパーミッション

> API: room/create.xml(新規)
> ルームを作成する
> 指定したルームが作成できない場合は、createをfalseにして返す
> 作成できた場合は、createをtrueにして返す
> 入力
> name: ルーム名
> password: ルームのパスワード 入っていない場合はパスワード制限なし
> perm: そのルームのデフォルトのパーミッション。ルームに参加したら最初はこのパーミッションになる
>
> anony: 匿名ログインを許可 true 不許可 false

>> パラメータ名変更
anon: 匿名ログインを許可 true 不許可 false

> 出力
> room.@create: ルーム作成成功 true 失敗 false
> room.@name: ルーム名
> room.@room_id: ルームのID

>> 追加
room.@perm: 入室するルームのデフォルトパーミッション