*SSTPサーバのできることを取得 [#jcd13031] SSTPサーバもいくつか種類があります。~ 中には簡易実装的なもの(([[SSTPViewer>http://sakura.nanika.jp/sstpviewer/]]とか))もあり、COMMUNICATEが全サーバに通じる、などという前提が難しくなってきました。 で、SSTPサーバの「できること」をきちんと取得できるようにしようというのがこのメモの目的です。 ''追記:''案1と2か3併用かなぁと。全部FMOに突っ込むとえらいことになりますし。 **案1''(改)''/EXECUTE GetProperty sstp [#h1befa0f] SSTP EXECUTEはまぁだいたい実装できるだろうという前提のもと、CROWの[[プロパティシステム>http://crow.aqrs.jp/devtest.html]]互換でsstpを追加して、SSTPサーバでできること、SSTPサーバのクセ等を取ろうという案です。 EXECUTE SSTP/1.4 Charset: Shift_JIS Command: GetProperty[sstp.commands] Sender: SSP SSTP/1.4 200 OK EXECUTE,SEND,NOTIFY,COMMUNICATE,GIVE,INSTALL EXECUTE SSTP/1.4 Charset: Shift_JIS Command: GetProperty[sstp.option] Sender: SSP SSTP/1.4 200 OK SecurityLevel,Marker -利点 --情報を追加し放題 --(拡張の仕方によってはGetの代替も含めて)一挙に必要な情報が取れる -欠点 --取得にコストが多少かかる **案2/FMOにエントリ追加 [#n573f153] sspfmo_83908390_76607660.info[1] CMD=EXECUTE,SEND,NOTIFY,COMMUNICATE,GIVE,INSTALL&OPTION=SecurityLevel,Marker (上記すべて1行) これが長ければ、利用可能コマンドだけ列挙、しかも略記して sspfmo_83908390_76607660.cmd[1]E,S,N,C,G,I -利点 --ローコスト -欠点 --ただでさえ不足気味のFMOが埋まる~ (サイズ拡張すれば非互換な処理系が出てくる) ---解決策:Sakura2 FMOとか作る? **案2.5/FMOエントリ追加+FINE [#n573f153] 本当にゴーストの数分だけバリエーションがあるかというと そうでもない気がしますので、 [Sakura FMO] sspfmo_83908390_76607660.infoclass[1]NORMAL sspfmo_83908390_98019801.infoclass[1]TEMPORARY [FINE FMO] SSP@37564000:infoclass: NORMAL=EXECUTE,SEND,NOTIFY,COMMUNICATE,GIVE,INSTALL&OPTION=SecurityLevel,Marker SSP@37564000:infoclass: TEMPORARY=SEND,NOTIFY,GIVE のように「情報のクラス」を規定するとか。 -利点 --SakuraFMOのサイズをそれほど圧迫せずに必要なだけの情報を展開できる -欠点 --読むほうも書くほうもとってもめんどい。 **案3/[[FINE>殊海夕音/FINE]]の大拡張祭 [#u6eaa6cd] ……。~ ※注:半分本気です。 -利点 --ネタが増える --今のうちなら影響範囲は小さい(笑) -欠点 --バグが増える #SAKURAFMO@sspfmo_83908390_76607660:GhostInfo: EXECUTE,SEND,NOTIFY,COMMUNICATE,GIVE,INSTALL&OPTION=SecurityLevel,Marker だとどうか。。。 FINE規格上で、「情報の提供のみを目的とした(つまり、FINEリクエストを受けることを想定しない)FINEサーバエントリはアプリケーション名の先頭に#を付ける。~ その場合Hwnd,Capability,ServerVersionの各プロパティを必須としない」とか変更が必要ですが。 **コメント欄 [#w1f3a2d9] #comment(below) - EKjMSINNUgC -- [[rblwkzx]] &new{2011-11-20 (日) 11:09:34}; -葵さんからの指摘で案1,1.5抹殺、案1改追加。 -- [[ぽな@ばぐとら]] &new{2004-12-13 20:30:11 (月)}; -案1.5追記。……2.5はさすがにアレですね、、、 -- [[ぽな@ばぐとら]] &new{2004-12-11 (土) 21:57:09}; -案3にもちっと追記してみたりしました。 -- [[浮子屋]] &new{2004-12-11 (土) 06:12:25}; -案2.5を書いてみたりしましたが…面倒なのでボツかなあ。 -- [[浮子屋]] &new{2004-12-11 (土) 05:54:15}; -略記パターンはちっと気持ち悪いですね。 -- [[浮子屋]] &new{2004-12-11 (土) 05:40:59}; -略記パターンを追加してみた。……拡張しにくそうだ。 -- [[ぽな@ばぐとら]] &new{2004-12-09 (木) 21:26:42}; -そうなると、FINEは処理系ごと前提で仕様を作りましたから、大改造が要ることになり、結局ほとんど新仕様に。弱ったなぁ、、、 -- [[ぽな@ばぐとら]] &new{2004-12-09 (木) 21:20:35}; -問題は、処理系ごと、ではなく、ゴーストごとで情報が変わってしまうということです。たとえば一時起動ゴーストはCOMMUNICATEができませんからそれを外すことになりますし。 -- [[ぽな@ばぐとら]] &new{2004-12-09 (木) 21:19:56}; -FMO使うならFINEのがいいような…案2だとサイズがやばそう(未対応アプリにまで影響の可能性あり)だし、案2+だと結局同じような規格をもういっこ作ることになるような。 -- [[浮子屋]] &new{2004-12-09 (木) 20:55:07}; -打てるコマンドのリストだけでもFMOに含めたいなぁと。Communicate先を探すのにいちいちEXECUTE乱発もアレですし。 -- [[ぽな@ばぐとら]] &new{2004-12-09 (木) 20:52:13}; -この件だけに限るなら、何度も行う処理ではないので多少のコストは目をつぶれる=案1、ですかね。 -- [[浮子屋]] &new{2004-12-09 (木) 20:31:26};