*SHIORI-EXE [#b5390feb]
DLLという、ベースウェア側に強く縛られる仕組みから開放しようという試み。
*基本概念 [#f5e944dc]
-SHIORIはDLLではなくEXEで実装。
-標準入出力でやりとりする。ベースウェア側でパイプをつなぐ。
-つまり、SHIORI側は「標準入出力(コンソール)を扱える開発環境」ならなんでも良くなり、開発の敷居が下がる。
--そのへんのプログラミング講座の導入部並の知識で頑張ればたぶんいける！…かも？
-ベースウェアとは別プロセスのため、CLR(.NET)だろうがなんだろうが、なんでも使える。
*仕様 [#pdca9cf6]
関数名:データバイト数[CRLF]~
以降データ(最後は空行終端)
パイプの両側（本体側・SHIORI側）ともに、書き終わったら必ずバッファをフラッシュすること。C言語のfflush。
**load [#h461acd1]
***入力 [#baaa70dd]
load:24[CRLF]
D:\hoge\hoge2\hoge3\[CRLF]
[CRLF]
***出力 [#x8269e72]
load:5[CRLF]
1[CRLF]
[CRLF]
**unload [#fcbba3ae]
***入力 [#pbf3c7a4]
unload:2[CRLF]
[CRLF]
***出力 [#gc8951a7]
unload:5[CRLF]
1[CRLF]
[CRLF]
**request [#ffde91a3]
***入力 [#x8ffd80f]
request:164[CRLF]
GET SHIORI/3.0[CRLF]
Charset: UTF-8[CRLF]
Sender: SSP[CRLF]
SecurityLevel: local[CRLF]
ID: OnSecondChange[CRLF]
Reference0: 4[CRLF]
Reference1: 0[CRLF]
Reference2: 0[CRLF]
Reference3: 1[CRLF]
Reference4: 0[CRLF]
[CRLF]
***出力 [#g0faae9d]
request:45[CRLF]
SHIORI/3.0 204 No Content[CRLF]
Charset: UTF-8[CRLF]
[CRLF]
*問題点 [#ef73ef18]
loadとunloadが手抜きすぎるのでなんとかする。特にloadの文字列の文字コード。
LOAD SHIORI/3.0
Charset: UTF-8
Reference0: D:\hoge\hoge\hoge
SHIORI/3.0 200 OK
Charset: UTF-8
Reference0: 1
UNLOAD SHIORI/3.0
Charset: UTF-8
SHIORI/3.0 200 OK
Charset: UTF-8
Reference0: 1
↑こんなんとか？
*コメント [#z807b338]
- 問題点がなにが問題なのかわからないです。文字コードの問題は親のSHIORIの規格でも同様の問題なのでは？ -- &new{2012-10-05 (金) 19:22:41};
- 親のSHIORIの規格での問題をそのままうつすのもどうなんだという。 -- [[ぽな]] &new{2012-10-05 (金) 19:40:40};
- 先にSHIORIのほうでFixしてからの方が良いと思う。 -- &new{2012-10-05 (金) 19:47:07};
- 追記。SHIORI-EXEは派生なのでやるのであれば大元のSHIORIで先に3.1なり作っておいて、他はそれに追従する形で対応する流れのほうが「SHIORI」なのに異なる使い勝手の「SHIORI」ができていってしまうので多分訳わからなくなると思う -- &new{2012-10-05 (金) 19:51:08};
- あくまでプロトコルはSHIORI/3.0で、その通信経路がWM_COPYDATAか標準入出力かの違いとしたほうが作業量が少ないし、自然かともいます。 -- [[さとー]] &new{2012-10-07 (日) 11:05:00};
- 汎用のperlやrubyをSHIORI.EXEにする場合、起動スクリプト指定が必要な気がします。descript.txtに「shiori.exe,parameter,"perlshiori.pl"」等。 -- [[さとー]] &new{2012-10-07 (日) 11:16:05};
- loadのパスですが、これは不要では。argv[0]で起動スクリプトのフルパスが入れば、それでカレントとすべきフォルダは指定できるので。 -- [[さとー]] &new{2012-10-07 (日) 11:26:32};
- ああ、そうか、通常SHIORIとの互換性維持のためなら、LOADはこうあるべきなのか。 -- [[さとー]] &new{2012-10-07 (日) 11:31:04};
- 文字コード問題は、起動スクリプトの中で自分の文字コードは決めておいてもらって、request/getversionでcharsetで返事してもらえばいい気がします。getversionは第1回目のrequestに来ることが慣習的に決まってますし、ここで返す文字列はascii/shift_jis/UTF-8いずれでも読み違える恐れはありません。 -- [[さとー]] &new{2012-10-07 (日) 11:37:10};
- load/request/unloadの後で与えているのがバイト数ですが、標準入出力をテキストモードで読むことを考えると、行数にするのも手ではないかと。どの文字コードでも、さすがにCRLFや\0が正当なもの以外で来ることは無いですし。 -- [[さとー]] &new{2012-10-07 (日) 11:42:15};
- 標準入出力もGLOBAL/LOCALも中身はテキストデータなのは変わらないという意味では、従来のSHIORIと同様にデータサイズで扱うほうが良いとおもいます -- &new{2012-10-08 (月) 06:58:42};
- スクリプト対応のための起動引数についてはちょっと思ったことがあったのですが、現状のSHIORIの考え方と変わってしまうように思います。 -- &new{2012-10-08 (月) 07:20:56};
- SHIORIの仕様上、loadの引数にはDLLのディレクトリパスが渡されます。SHIORI-EXEの場合はEXEのディレクトリパスですかね。プログラムが固有のデータを扱う場合はこのパスにファイル一式を格納しなくてはなりません。引数による対応にすると、ランタイムのパスに書き込むことになり、この仕様を変えなくてはならなくなります。 -- &new{2012-10-08 (月) 07:21:06};
- SHIORI-EXEの仕様の前提として、(汲み違ってたらごめんなさい)自身がEXEディレクトリパス上で実行可能な実行（関連付け起動）可能ファイルになっていると思います。 -- &new{2012-10-08 (月) 07:21:14};
- 将来を考えたよからぬ発想として、「perl/ruby/pythonはSSPが同梱」というのを考えました。これが実現すると、ゴーストがSHIORI.EXEを持つ必要がなくなります。この場合は、スクリプトと使用するSHIORI.EXEをdescript.txtに描くだけで良くなります。（まあ今は大風呂敷の世界ですが） -- [[さとー]] &new{2012-10-08 (月) 11:26:13};
- 同梱については再配布など色々面倒な点がありそうなので、ぽなさんと要相談だと思う -- &new{2012-10-08 (月) 11:43:02};
#comment
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
