仕様書出せといわれたので考えてみる

目的

1. GHOSTディレクトリではなく、本体側が持つSHIORIを呼び出すための仕組み
2. .netで作ったSHIORIを呼び出すためのラッパーDLLを処理系本体側が持つための仕組み

[ゴーストディレクトリ]ghost/master/descript.txt

• shiori.plugin 本体側SHIORIの名前（例：shiori.plugin,callDotNet）

[本体ディレクトリ]/[どこか、pluginディレクトリとか？]

この辺の仕様は、PLUGIN/2.0と同じでいいかも。DLLのAPIが違うのでSHIORI_PLUGIN/1.0とする？

PLUGINインターフェース

SHIORI_API BOOL __cdecl load(HGLOBAL hGlobal_loaddir, long loaddir_len);

SHIORI_API HGLOBAL __cdecl request(HGLOBAL hGlobal_request, long* ptr_len);

SHIORI_API BOOL __cdecl unload(void);

ここまではSHIORI_APIと同じ。これはSHIORI_PLUGIN自体のload/unloadとする。
SHIORI_PLUGINの場合、request関数は存在するだけで使わない。
unloadコマンドが実行されたとき、まだUNLOADされていないすべてのゴーストのデータをUNLOADする。
hGlobal_loaddirの引数はSHIORI_PLUGINのディレクトリ。

SHIORI_PLUGINインターフェース

HRESULT __cdecl ghost_load(int ghost_id,[in]BSTR loaddir);

HRESULT __cdecl ghost_request(int ghost_id, [in]BSTR request, [out]BSTR* response);

HRESULT __cdecl ghost_unload(int ghost_id);

通常のSHIORI APIとの違いは以下のとおり

• 先頭にghost_idがつく。IDは処理系がおそらく持っているであろう識別IDそのままでOK。UNLOADされるまでゴーストを識別するために利用する。
• COMインターフェース風、文字列のやり取りはBSTR（なのでlength引数廃止）。戻り値はHRESULT。

備考

つまり、SHIORI APIのインターフェースをCOMの引数にし、更にゴーストを識別するためのIDをつけました。

追伸

• 最初はghost_idを変えただけにしてた。
• 次はWIDE_CHAR文字列にしてみたりした。
• よく考えたらOS推奨の文字列のやりとりはBSTRなので、BSTRに変更。さすがに全面COMインターフェースにするのはやりすぎなので今のところはやめておきますが、はい。
• ‥‥でも、ここまでするならもう、COMオブジェクトにしちゃったほうがいいのかなぁ。どうなんだろう？