GetStatus

SSTP Execute GetStatus、提案ではgetSVStatusとなっていますが、これについてのメモです。

http://seriko.nanika.jp/sstpviewer/bbs/board.cgi?log=32

仕様案ラフ

SSTP/1.4 200 OK
Charset: Shift_JIS
DefaultGhost: Emily,Teddy
ExePath: E:\tool\sv\SSTP-Viewer.exe
Quiet: 1,TRUE
SSTPQueueLeftItem: 0
SSTPQueueLeftLength: 0
Talking: 1,TRUE
TimeCritical: 1,TRUE
UserName: ぽな
X-SV-OverBoost: 0,OFF
X-SV-SVGSettingFile: E:\tool\sv\ghost.txt
X-SV-TalkSpeed: 0,はやい
X-SV-WindowStatus: 0,READY

追加:Talking(0,FALSE/1,TRUE)

要点は

  • どのSSTPがらみのアプリも 要素名: 値 の解析部を持ってるだろうと思われるので、わかりやすいほうがいいし、3バイト固定は必要なさそう?
  • カンマとバイト値1が区切りなことが多いのでそれに統一したほうがいい……かも?
  • S-Vだけが実装するとも限らないので、S-V依存の設定にX-SV-とつけた
    さらに名前もGetStatusとし、その他多少修正

その他ツッコミ

EXECUTE CheckQueue

ninix-ayaに、EXECUTE CheckQueueを送信して

SSTP/1.4 200 OK
2

というふうに返す仕様がすでにあります。これとQueueがらみの上記のプロパティをどうするか……まぁ、両方実装すればいいんでしょうけど。

  • ninix-ayaのこれは、「このコマンドを発行したSSTPクライアントが、過去に送信しキューにためてあるSSTPの数」なんですよね。おそらくHWndを見て抽出をかけている‥‥で、SVで出しているこれは「SSTPクライアントに関わらず、キューに溜まっているSSTPの数」だから、若干意味合いが違っています。‥‥それで同じコマンドだったら却って混乱すると思ったんですが、ぽなさんどう思います?(T=J.)
  • いっそ、同じ仕組みをこっそり仕込むとか?
  • できますけど‥‥このninix-ayaの仕様、なんでこうなってるか分かんないんですよね(汗)セキュリティ的な要因なんでしょうか?(T=J.)
  • よー考えたら、全部あわせたQueueのサイズが分かったほうがいいですな。というわけで、CheckQueueの考慮はとりあえずポイでしょうか。
  • でしょ?用途があるのならCheckQueueも実装しますけど‥‥?(T=J.)

プロパティシステム

http://crow.aqrs.jp/devtest.html

あとはこれとの兼ね合いでしょうか。
まぁ、こっちは実装が複雑だから勘弁して!と思うかもしれませんが(汗

他のEXECUTE等とフォーマットが統一されていない

……まぁ、今も統一されてないのでどっちでもいいやといえばいいわけですが。

SSTP/1.4 200 OK

データ

と、コマンド行・空行(・データ行・空行)、が今のSSTPの戻り値のスタイルですから、これとの兼ね合いはどうなのかなぁと思いました。

  • ですので、最初に挙げた最初の3文字を識別因子とするやりかたは、「因子:値」をまとめて「ひとつのデータ文字列」として扱うというスタンスでした。書式をあえて変えていたのはそういう理由です。んで、ここについては結論がでたということでいいんじゃないですかね?(T=J.)
    • あー‥‥いや、そうでもないのか。「 Charset: Shift_JIS  DefaultGhost: Emily,Teddy 」の場合、Charsetは「SSTPの属性」で、DefaultGhostは「サーバーの属性」だからコンテキストが違う。それが同じ構文で並べられているのは、やっぱり、変なのかもしれない。サーバーの属性名に予約語(SSTPの属性名)が使えないなんてことになるし。(T=J.)
    • Charsetなんて使わないでしょうし、絶対必須な予約語としてはCharsetとせいぜいValue、Reference?くらいですし。
    • まぁ、そうなんですけどね。(T=J.)

とはいえ、これじゃCharsetヘッダもつけられず散々な状態ですからね。
いっそXSSTP/1.0とかにしてしまうか……

  • この場合のCharsetはS-JISとして扱うと、MATERIAの仕様書で書いてますね。(T=J.)
    • だから、SSTPにおける文字コードサポートの線引きが気になっていたんですけど。あるいは、SEND SSTPに比べEXECUTE SSTPはあくまで補助的な機能であるとlsさんは考えていたのかもしれませんね。(T=J.)
    • SSPの実装はリクエストのCharsetにあわせる、なので、この時点で互換がすでに崩れてることになるのかな……
    • もっとも、文字コードが問題になるのはGetNameくらいなんですよね?FMOがある以上、使われる事はあまりないと推測していますが‥‥。(T=J.)

雑談タイム


  • 結論として実装しましたので、もう変更不可能です。クローズお願いします。どうもありがとうございました。 -- T=J. 2005-02-23 13:02:28 (水)
  • 更新更新。 -- T=J. 2005-02-17 14:54:59 (木)
  • さらに考慮すべき点をひとつ追加しました。……実はどっちでもいいんですけどねこれ。 -- ぽな@ばぐとら 2005-02-16 17:10:39 (水)
  • 本当だ‥‥GetStatus‥‥ですか‥‥? -- T=J. 2005-02-16 16:04:14 (水)
  • ところで……そろそろメソッドの名前の頭、大文字ですよってTJさんにツッコミいれたほうがいいのだろうか。 -- ぽな@ばぐとら 2005-02-15 23:49:50 (火)
  • ありがとです。‥‥では、あまり深く考えなくてもよさそうですね>夕音さん / getNamesが実装済みです。>ぽなさん -- T=J. 2005-02-15 22:12:22 (火)
  • GetSVGStatusをつけるなら、インストール済みSVGの列挙メソッドもつけないといけませんね。 -- ぽな@ばぐとら 2005-02-15 22:07:00 (火)
  • 私のFINEコンポーネントでは出来ませんが、構文解析用のコンポーネントは別件で作りましたね。DSSTPライブラリの使い回しは浮子屋さんがされてたと思いますが。 -- 殊海夕音 2005-02-15 22:04:53 (火)
  • あー‥‥あと、話は少し変わって、getSVGStatusとか‥‥配布URL等のSVGの情報を取り出せる‥‥あんまり意味ないですかね? -- T=J. 2005-02-15 22:04:19 (火)
  • 今のところ、上に挙げたので十分でしょうかね>取得 -- ぽな@ばぐとら 2005-02-15 22:00:01 (火)
  • ‥‥そもそも、S-Vから何が取得できたら便利なんでしょう‥‥? -- T=J. 2005-02-15 21:37:37 (火)
  • ‥‥あ。失礼、SocketSSTPなら環境乗り越えて実行できますから相手環境の時刻を調べられることには大きな意味がありますね。 -- T=J. 2005-02-15 21:36:17 (火)
    • さらに失礼、setPropertyが出来れば\6とか不要ですね。 -- T=J. 2005-02-15 21:47:38 (火)
  • system.yearとかは、現在SHIORIが自力でOSから取ってるのをベースウェアから取れるように、と言う事を考えてるんじゃないでしょうか? -- 殊海夕音 2005-02-15 21:26:27 (火)
  • そのライブラリって単なる構文解析のメソッドだけ使ったりできます?‥‥てか、DSSTPライブラリってサーバーもクライアントもこなせたりする?>夕音さん -- T=J. 2005-02-15 21:26:00 (火)
  • FINEはDSSTPライブラリをそのまま流用出来るように設計したのでSSTPもどきになってます。 -- 殊海夕音 2005-02-15 21:24:55 (火)
  • crowのプロパティシステムなんですが‥‥system.yearとか取る必要あるんでしょうか?(笑) -- T=J. 2005-02-15 21:23:49 (火)
  • (‥‥なぁ、この会話って俺会社から帰って家でIRCでやった方が‥‥とか思ってみたけど、ログ残る方がいいか(笑)) -- T=J. 2005-02-15 21:19:57 (火)
  • りょーかいです、じゃ、3文字は止めにして、所長さん案に乗りましょう。 -- T=J. 2005-02-15 21:18:57 (火)
  • ……GetNameは過去互換ですorz ホントはそう書きたい! -- ぽな@ばぐとら 2005-02-15 21:18:34 (火)
  • じゃgetNameとかも「value: さくら」とか返した方がよいとかいう根本的なツッコミがw -- T=J. 2005-02-15 21:17:53 (火)
  • まぁ、大文字3文字だと、IPv4枯渇問題みたいな始末になるのと、解析はしやすいけど素で読みにくいという問題がありますね。 -- ぽな@ばぐとら 2005-02-15 21:17:48 (火)
  • FINEはほぼSSTPと同じって言う点が却ってややこしいと思ってるんですけど‥‥ま、これが一般的な書き方‥‥ということになれば反対する理由はない‥‥のかな? -- T=J. 2005-02-15 21:16:10 (火)
  • 無理に縮めると後々見通しが悪くなる気が。 -- 殊海夕音 2005-02-15 21:13:32 (火)
  • 今のクライアントは殊海夕音/FINEとかで簡易サーバ的な役割も実装している可能性も多くて、たぶん解析できるだろという淡い期待のもとにこう書き直してみました(笑 -- ぽな@ばぐとら 2005-02-15 21:10:34 (火)
  • 単に、簡易SSTP受信ツールが今後出て来ないとも限らないわけで、その時にリクエスト文字列にSVなんたらってついてたら実装しにくいだろうなぁということで、汎用的なものを考慮してるわけじゃないです。完全に汎用的なものは要するにCROW提案のプロパティシステムに丸投げですから。 -- ぽな@ばぐとら 2005-02-15 21:07:24 (火)
  • 素ツッコミ。SSTPサーバーはそうですが、クライアント側って「要素名: 値」の解析必須‥‥ではないですよね(^^; -- T=J. 2005-02-15 20:58:58 (火)
  • それと、たとえばS-Vとベースウェアは構造が違いますから、たとえばSVGディレクトリを取得するのに汎用的なコマンドが居るのかどうか‥‥という問題もありますね。 -- T=J. 2005-02-15 20:44:26 (火)
  • あまり大がかりなのを考えてると、S-Vがいつまで経っても終わらないので、S-Vが必要な情報だけ考えて居るんですけど‥‥(汗 -- T=J. 2005-02-15 20:39:46 (火)
  • うわ書き込みの反応早ッ!!EXECUTE CheckQueueのツッコミのツッコミ入れておきました。 -- T=J. 2005-02-15 20:37:46 (火)
  • 一応書いてはみたものの、プロパティシステム云々はおまけです。仕様規模がデカすぎて面倒でしょうし。 -- ぽな@ばぐとら 2005-02-15 20:36:25 (火)

トップ   編集 凍結 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-12-09 (土) 22:52:40