[Apache Shindig][お勉強][OpenSocial] メモ91 gadgets.rpc(3)

JavaScript難しい・・。

features/rpc/rpc.jsをざっと眺めてみた。

あっているかどうかしらないけど、多分流れ的にはこんな感じだと思う。

gadgets.rpcの流れ
1) gadgets.rpc.callが呼ばれる
2) gadgets.rpc.callの中で、postMessageなるものを使って別ドメインのiframeな感じのJavaScriptへメッセージ送信
3) rpc_relay.htm内でgadgets.rpc.receiveをコールし、postMessageで送信されたメッセージを受信し、該当コールバックを実行。
メッセージの内容はJSON形式の文字列で、

  s: Service Name
  f: From
  c: The callback ID or 0 if none.
  a: The arguments for this RPC call.
  t: The authentication token.

といった内容。


gadgets.rpc.receive
postMessageで送られてくるJSONを元に、実際に処理をコールするところっぽい。
やっていることは以下の感じ。
1) securityTokenの値をチェック。だめならException
2) AsyncなRPCのためにcallbackをrpcコンテキストにくっつけておく
3) すでに登録されているサービスを実行
4) コールバックをコール。(gadgets.rpc.call経由で)

多分こんな感じ。
すでに登録されているサービスというのは、
gadgets.rpc.registerメソッドで登録される。
gadgets.rpc.registerの定義は、

   register: function(serviceName, handler) {
      if (serviceName === CALLBACK_NAME) {
        throw new Error("Cannot overwrite callback service");
      }

      if (serviceName === DEFAULT_NAME) {
        throw new Error("Cannot overwrite default service: use registerDefault");
      }

      services[serviceName] = handler;
    },

となっていて、registerがコールされるとservicesメンバ変数(呼び方がわからん！)に
function(上記だとhandlerがそれにあたる)が保存される。




ところで、

===

って'='が3つ続いているけど、これは何？？？？


--
大体分かったつもりだけど、どうしてrequestSendMessageはgadgets.rpc経由にするんだろう。。
そんな必要ない気がするんだけど。。

requestSendMessage should use the RPC mechanism as similar features do

って言ってる。。

ってことは、親なり別frameなりでダイアログでも表示させるってことかしらー。

--
ははぁーん。

What we want to do is just send a message as soon as a gadget asks us with
the requestSendMessage method.

という投稿発見。
それに対して、

I think, though, the default implementation should really be to send
 an RPC to the containing page

だって。

これでRPC経由になったのかしら。
ところで、何て仰っているのかな？


.