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とし、その他多少修正
その他ツッコミ†
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
あとはこれとの兼ね合いでしょうか。
まぁ、こっちは実装が複雑だから勘弁して！と思うかもしれませんが（汗
雑談タイム†
- ありがとです。‥‥では、あまり深く考えなくてもよさそうですね＞夕音さん ／ getNamesが実装済みです。＞ぽなさん -- T=J.
- GetSVGStatusをつけるなら、インストール済みSVGの列挙メソッドもつけないといけませんね。 -- ぽな@ばぐとら
- 私のFINEコンポーネントでは出来ませんが、構文解析用のコンポーネントは別件で作りましたね。DSSTPライブラリの使い回しは浮子屋さんがされてたと思いますが。 -- 殊海夕音
- あー‥‥あと、話は少し変わって、getSVGStatusとか‥‥配布URL等のSVGの情報を取り出せる‥‥あんまり意味ないですかね？ -- T=J.
- 今のところ、上に挙げたので十分でしょうかね＞取得 -- ぽな@ばぐとら
- ‥‥そもそも、S-Vから何が取得できたら便利なんでしょう‥‥？ -- T=J.
- ‥‥あ。失礼、SocketSSTPなら環境乗り越えて実行できますから相手環境の時刻を調べられることには大きな意味がありますね。 -- T=J.
- さらに失礼、setPropertyが出来れば\6とか不要ですね。 -- T=J.
- system.yearとかは、現在SHIORIが自力でOSから取ってるのをベースウェアから取れるように、と言う事を考えてるんじゃないでしょうか？ -- 殊海夕音
- そのライブラリって単なる構文解析のメソッドだけ使ったりできます？‥‥てか、DSSTPライブラリってサーバーもクライアントもこなせたりする？＞夕音さん -- T=J.
- FINEはDSSTPライブラリをそのまま流用出来るように設計したのでSSTPもどきになってます。 -- 殊海夕音
- crowのプロパティシステムなんですが‥‥system.yearとか取る必要あるんでしょうか？（笑） -- T=J.
- （‥‥なぁ、この会話って俺会社から帰って家でIRCでやった方が‥‥とか思ってみたけど、ログ残る方がいいか（笑）） -- T=J.
- りょーかいです、じゃ、３文字は止めにして、所長さん案に乗りましょう。 -- T=J.
- ……GetNameは過去互換ですorz ホントはそう書きたい！ -- ぽな@ばぐとら
- じゃgetNameとかも「value: さくら」とか返した方がよいとかいう根本的なツッコミがｗ -- T=J.
- まぁ、大文字3文字だと、IPv4枯渇問題みたいな始末になるのと、解析はしやすいけど素で読みにくいという問題がありますね。 -- ぽな@ばぐとら
- FINEはほぼSSTPと同じって言う点が却ってややこしいと思ってるんですけど‥‥ま、これが一般的な書き方‥‥ということになれば反対する理由はない‥‥のかな？ -- T=J.
- 無理に縮めると後々見通しが悪くなる気が。 -- 殊海夕音
- 今のクライアントは殊海夕音/FINEとかで簡易サーバ的な役割も実装している可能性も多くて、たぶん解析できるだろという淡い期待のもとにこう書き直してみました（笑 -- ぽな@ばぐとら
- 単に、簡易SSTP受信ツールが今後出て来ないとも限らないわけで、その時にリクエスト文字列にSVなんたらってついてたら実装しにくいだろうなぁということで、汎用的なものを考慮してるわけじゃないです。完全に汎用的なものは要するにCROW提案のプロパティシステムに丸投げですから。 -- ぽな@ばぐとら
- 素ツッコミ。SSTPサーバーはそうですが、クライアント側って「要素名: 値」の解析必須‥‥ではないですよね（＾＾； -- T=J.
- それと、たとえばS-Vとベースウェアは構造が違いますから、たとえばSVGディレクトリを取得するのに汎用的なコマンドが居るのかどうか‥‥という問題もありますね。 -- T=J.
- あまり大がかりなのを考えてると、S-Vがいつまで経っても終わらないので、S-Vが必要な情報だけ考えて居るんですけど‥‥（汗 -- T=J.
- うわ書き込みの反応早ッ！！EXECUTE CheckQueueのツッコミのツッコミ入れておきました。 -- T=J.
- 一応書いてはみたものの、プロパティシステム云々はおまけです。仕様規模がデカすぎて面倒でしょうし。 -- ぽな@ばぐとら
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
