Ikagaka Ghost API 1.0 (WD)

[legokichi]

Ikagaka Ghost API 1.0の仕様についての議論スレッドです。

うにゅう＠もどき板の意見も拾いますのでGitHubのアカウントをお持ちでない方はそちらもご利用ください。

ご意見お待ちしています。

[legokichi]

ベースウェアにこの栞が対応していることを伝える方法

[legokichi]

Ikagaka Ghost APIよりもIkagaka Shiori API のが適切な名前では

[Narazaka]

現状のGhost.jsには 1.栞を判定し、読み込む互換栞を決定する部分 2.栞と通信する部分 の2つが含まれています。

如何かの動作環境としては現状以下の種類が想定されます。

1. ブラウザ上 - スレッドはWebWorkerのみ / FSはBrowserFS on IndexedDB / JS栞のみ利用可能
2. Windows上 - スレッドはchild_process利用可能 / FSはnodeFS利用可能 / オリジナルの栞DLLをネイティブで動作できる
3. Windows以外のPC上 - スレッドはchild_process利用可能 / FSはnodeFS利用可能 / JS栞のみ利用可能
4. Cordova上 - スレッドはWebWorkerのみ / FileSystem APIライクなPhoneGap FileAPIあるいはCordovaFileSystem / JS栞のみ利用可能

以上から以下の場合が想定されます。 ・JS栞を使用する場合 　・ネイティブFSを使う場合 - FSはJS栞側で処理するのが効率的(Ghostの引数にFSはいらない) 　・互換FSを使う場合 - FSは栞のload()前に栞が参照するFSに書き込む必要がある(Ghostの引数にFS必須) 　・FSを使わない場合 - JS栞によってはFSを使わないという選択が可能 ・Windows上でDLLを使用する場合 　・ネイティブFSを使う - FSは栞側でのみ処理できる(Ghostの引数にFSはいらない)

判定系は栞と独立で、これら栞の選択とFSの有無判定までをまかせて、必要な場合の中身渡しと栞のロードと通信確保をGhost.js、スレッドの動作は栞側にまかせるというのが妥当な施策だと考えます。 判定系もAPIというかプラグイン仕様的な奴を定める必要があるかと。

[Narazaka]

Windows上でオリジナルの栞DLLをネイティブで動作させるというものは、簡単な方法としては「shioridllproxy.exe的なのに栞パスを渡してexecFileしstdioで通信するようなJS栞」をつかうなどがあります。

[Narazaka]

また将来的にnodeっぽいrequireが実現できるならば、descript.txtにゴースト独自のJS版栞を記述させ、それを読み込むということも考えたい。

[Narazaka]

これも「shiori.dll.jsをサンドボックスっぽいとこでrequireしてloadとか呼ぶようなJS栞」を使うことでいけそうです。 このrequireしてloadとか呼ぶような仕様は如何かの管轄ではなく「そのようなJS栞」の管轄になりますが。

[Narazaka]

FSは必ず渡すが、その中身は実FSか仮想FSかを問わずnode.jsの非同期FSのAPIをみたしたものであることが保障されるとかかな？それと別にこれが実FSなのかどうかとかのフラグを渡すとして。

[legokichi]

閑話休題。自分用メモ。

如何かはオンラインゴースト「Ghost as a Service(GaaS)」を目指したい。 その実現方法としては、

1. 栞をWeb Serverで動かして、SHIORI over HTTPする。そのオフラインプロキシとして従来の栞を位置づける
2. 従来の栞を利用して、栞がSHIORI over HTTP投げる の２種類ある。2のが従来のmateria、SSPなどでも動く。

[legokichi]

自分用メモ。

Ikagaka仕様において、各コンポーネントの役割。

• Ikagaka Named API（仮）
  • Named API を通じてシェル描画をする。
  • 実際のシェル描画はShell.jsとBalloon.jsに一任。
  • Shell描画エンジンの選択とShellチェンジはベースウェアの仕事。
  • Shell.js
  • 責任範囲は/[GhostName]/Shell/[ShellName]/ディレクトリ以下。
  • Balloon.js
  • 責任範囲は[BalloonName]/ディレクトリ以下。
  • NamedMgr
  • ウインドウシステム。複数のゴーストの重なりを管理する。
• Ikagaka Ghost API（仮）
  • SHIORI requestとSHIORI responseを通じてSakuraScript生成する。
  • 責任範囲はGhost/**ディレクトリ以下。
  • SakuraScript生成エンジン(栞)の選択はベースウェアの仕事。
• Nanika
  • イベントマネージャ。
  • 責任範囲は/[GhostName]/ディレクトリ以下。
  • Named API通じたSakuraScript再生。
  • Shellチェンジ、Balloonチェンジ。
  • 実際のイベントはNanikaPluginで記述する。素のNanikaは何も通知しない。
  • NanikaPlugin
  • Nanikaが通知するイベントを記述する。
  • SakuraScriptPlayer.js
  • SakuraScriptを解釈してタイミングに応じてNamedAPI呼ぶことでSakuraScriptを再生する。
  • NanikaMgr
  • 複数のNanikaを管理する。
  • Nanikaの起動（＝ゴーストの起動）、交代、終了など。
  • ゴースト間コミュニケーションも。
• ベースウェア
  • 環境に応じたFS選択しNanikaMgrに渡す。
  • NamedMgr初期化
  • NanikaMgr初期化
  • NanikaMgrにベースウェア終了を通知

[legokichi]

http://twilog.org/duxca/date-150201/nort この辺の議論の末、 new Ghost(fs, path) か new Ghost(NanikaStorage, ...) のどちらかにしよう、arraybufferは良くないという結論になりました

[legokichi]

node-fs互換の利点は学習コストが少ないこと、 NanikaStorageの利点は各種ファイルやディレクトリへの便利API含んでるので実装が楽なこと、バックエンドにfsの他にも使えそうなこと

です

[legokichi]

NanikaStorageが仕様化できればGhostだけでなくNamed APIのShell、Balloonでも使って行こうと考えてます

[Narazaka]

NanikaStorageの仕様化一応やりました。

[Narazaka]

NanikaDirectoryの仕様とあわせて storage.shell(ghostpath, shellpath) .then (directory) => files = directory.asArrayBuffer() とできます。

[legokichi]

NanikaStorageからFS wrapperとして必要そうなものを抽出してみました https://github.com/Ikagaka/Ikagaka.js/wiki/Ikagaka-1.0-API-Specifications#ikagaka-storage-api

[legokichi]

BrowserFS: Buffer返すのキモい FileSystemAPI: そんなものなかった { [path]: ArrayBuffer; }: メモリ食うのでない NanikaStorage: 独自API、けどすでに内部的に実装されてる

ので、BrowserFSをラップしたNanikaStorageが採用される見込みです

[legokichi]

{ [absPath]: (data?:arraybuffer)=> Promise<ArrayBuffer>; }ならすべて解決するのでは

[legokichi]

これまでの候補と私の認識

• node-fs互換BrowserFS
  • 利点：学習コスト低い。backendにいろいろ使える。絶対/相対パス。
  • 欠点：Bufferつかいたくない
• HTML5 FileSystem API
  • 利点：将来的に標準化される。
  • 欠点：APIがありえないくらい冗長。現在Chromeしか使えない
• NanikaStorage
  • 利点：すでにNanikaの中で使われてる。便利機能。相対パス。
  • 欠点：独自仕様。いまいちシンプルでない。
• { [absPath]: ArrayBuffer; }
  • 利点：シンプル。絶対パス
  • 欠点：メモリバカ食い
• { [absPath]: (data?:arraybuffer)=> Promise<ArrayBuffer>; }
  • 利点：シンプル。絶対パス
  • 欠点：ディレクトリ生成、ファイル書き込みが冗長かつイケてない
• fso
  • 利点：シンプル。ツリー構造。バックエンドにBrowserFS。
  • 欠点：独自。Buffer

要件

• Ghost/Shell/Balloonのコンストラクタ引数を共通にしたい。
• Ghostは他のディレクトリにもアクセスできるような自由が欲しい→{ [absPath]: ()=> Promise<ArrayBuffer>; }はサンドボックス
• 第三者がアクセスするAPIなので自由度が高くシンプルなものがよい→NanikaStorageは冗長、fsoは独自仕様
• Ghost/Shell/Balloonともにブラウザ環境での動作を前提にしている→BrowserFSのBufferは冗長
• IkagakaはUkagakaをシミュレートする環境である以上、FileSystemをシミュレートする必要がある

[legokichi]

私の順序としては

1. BrowserFS - 結局どの候補つかっても内部的にはBrowserFS使うのでは
2. NanikaStorage - ノウハウの塊
3. { [absPath]: (data?:arraybuffer)=> Promise>; } - 現状維持しつつ非同期化
4. { [absPath]: ArrayBuffer; } - 現状維持
5. fso - BrowserFSをTree化する必要性があんまりない
6. FileSystem API - 時期尚早すぎる

です。

[Narazaka]

Ghostにはfsを渡すべきではないか。 directory: { [filePath: string]: ArrayBuffer; }という現状維持案はベースウェア側がファイル保存処理を行っている。 しかしGhostはつまることろSHIORIであり、本来ファイル操作についてはベースウェアは関知しないはずである。 なのでFSに書き戻し可能なオブジェクトを渡し、この責務をベースウェアからはずすべきでは。 load,unloadにネイティブのSHIORIの仕様以外のことをさせているのは分かりづらく気持ち悪い。