雑感
フレームワークとしてはコンダクター(conductor)が主役だなw
コンダクターのAPIの出来が成否を分ける気がする。
成否の基準は、自分のやる気が持つかどうか、だけだけどw
とりあえず考えるべきなのは、
- レセプター(receptor)が叩くAPI
- パフォーマー(performer)がイベントリスナーを登録するAPI
- アクター(actor)とやり取りするAPI
- 同一ドメインの他のがらくた(CRAP)と通信するAPI
くらいだな。
APIを考えるのと同時に通信方法も考えないと。
ハッキリ言って、通信コストがめっちゃ高いシステムになる。メッセージ駆動でデザインしてるんだから当然と言えば当然なんだけども。
単純にイベントリスナー等を使ってコールバック関数を呼べば済むものから、受け渡すデータをディープコピーしてスレッドはおろかwプロセス間のメッセージで渡すしか無いものまであると思う。
いずれにせよ、ユーザーがその辺を意識しないで済むように、ラップして統一した使い方が出来るようにしないとね。
ザクッとでも案が出来たら、泥臭〜くTypeScriptあたりでモックアップを試作してみて、色々試してみよ〜っとw
がらくたのイメージ追記
汎用性を考えると、同一ドメインの別ウインドウや別タブと協働できる仕組みも必要だな。
今後の課題としてw
まあ、この考え方だと、conductor間の通信って形になるよなぁ
がらくたCRAPのイメージ
ユニットの概要
| 役割 | スレッド | 機能 |
| receptor | メイン | UIによるイベントを受け付けてconductorに渡す |
| performer | メイン | conductorからの指示によりDOMを操作する |
| conductor | WORK | 各ユニットから通知を受け取り、調整して、必要な通知を飛ばす |
| actor(s) | WORK | 処理の本体。基本的に一つから数個で構成。conductorからの指示により処理を行う。actor間の通信もconductorを経由する |
スレッド間の関係
メインスレッド
+receptor
+performer
+conductor
+actor 1
+actor 2
:
+actor n
ユニット間の関係
receptor → conductor → performer
⇅
actor(s)
とりま、こんなところかな。
CAPモデルとworkerの仕様の齟齬w
ブラウザ上でCAPモデルを使うとするじゃん？
シングルタスクで動かすわけないから、workerを使ってマルチスレッド化するじゃん？
CAPモデルでは
- (C)コンダクター ⇆ (A)アクター
- (C)コンダクター ⇆ (P)パフォーマー
の通信を行うんだから、コンダクターが親になってアクターとパフォーマーを(workerとして)生成するのが自然じゃん？
コンダクターが配下のスレッド( = worker)を全て把握するんだから。
なのに、ブラウザエンジンの仕様見てると、マスタースレッドしかDOMを扱えないとなってる orz
webassembly が動くメジャーなブラウザ全てでww
必然的に(直接表示を行う)パフォーマーがマスタースレッドとなる。
パフォーマーがコンダクターを別スレッドで起動して、コンダクターがその他のアクターを起動する形になりそう。
つまり、「パフォーマー ⇆ コンダクター」の通信と、「コンダクター ⇆ アクター」の通信は、別物になるってことだ。
さらに言えば、メインスレッドでしかUI/UX系のイベントが受け取れないんだから、パフォーマーが入力受け付け機能を持つしか無いじゃん？
……ツラたん。
CAPモデル
私が思うに、まずは分業体制の観点から、入力、内部状態遷移、出力は、完全に分離されなければならない。
また非同期処理について人間が(なるべく)意識せずに済むようにしなければならない。
分業体制を考えるにあたり、
- (C)コンダクター
- 入力機能。(コントロール等による)イベントの制御を行う。DOMやバックエンドのウェブサーバーとの通信等で発生するイベントを制御する。非同期処理の競合を調整したりするのも役目になると思う。調整されたイベントを後述のアクターに通知する。
- (A)アクター
- 状態遷移の具体的な処理を行う。「状態(オブジェクト )」じゃなくて「状態遷移(処理)」。通知されたイベントと自分の状態(これはオブジェクト、てかプロパティか？)に基づく処理を行う。一般的なプログラムのイメージ。必要に応じて連動する別物ユニットに処理を依頼することになるが、これはコンダクターを介して行う。
- (P)パフォーマー
- 出力機能。ビューの生成や表示を行う。HTML+CSSのイメージ。フレームワーク的には、アクターからの(コンダクター経由での)要請により、DOMツリーの生成、変更、削除を行う。ScssなりCSSを動的に制御できるのならそれも行う(要調査)
ってあたりをたたき台にして考えてみようと思う。
「MVC」じゃ無くて「CAP」ね。
ノット MVC
何度も同じ話するけど、私は、MVC(モデル・ビュー・コントロール)って考え方はしない。
MVCモデルを否定してるわけじゃないよ。
コンピュータの黎明期から、てかその数学的モデルであるチューリング・マシーンにしてからが、「入力 → 内部状態遷移 → 出力」という「フレームワーク」に従ってるし、そのおかげで成功を収めて来た。
MVCも、C=入力、M=内部状態(遷移)、V=出力であって、コンソールアプリのそれをGUI用にリ・モデリングしたところに手柄がある。
とはいえ、時代の要請もあって、その概念はオブジェクト思考に縛られている。
人間の頭はオブジェクト思考に適してないのでw 結局はソフト開発が大規模化したり複雑化したりするにつれ、難しくなってきた。
時を同じくして発展してきた非同期処理(CPUのマルチコア化とか、linuxとかだと軽量なスレッドの発展とか)が、また人の思考の限界を超えててw 物事を難しくしてる。
ツール(道具)の進化に使う側が付いていけてない。
だからこそ、それをサポートするフレームワークが必要になる。
