OSSなマンガ作成支援ツールの素案(1年半ぶり8回目)5(Git連携、トランザクション考)

やあ (´・ω・`) ようこそ、セルフまとめへ。 このテキーラはサービスだから、まず飲んで落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このまとめタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい 続きを読む
2
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

ああ、ここに追加が必要だ。 やはりGitとの連携は必要だろうという結論に至る。しかしGitとの連携とはなんぞや? gitがjsもしくはWebAssemblyに実装されていれば、何かできるが、githubとの連携は困難を極めるだろう。もちろんどっかに中継サーバーを立てるのであれば不可能じゃないんだけどね。

2019-01-05 23:25:44
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

対攻撃耐性を構造的に持ちたい。 要件的には、GitHub接続に中間サーバーが必要であるというのはあまりよろしくない。 ①DDoSを受ける鯖は静的資材配布鯖以外置かない ②配布鯖は攻撃者が問題視する加工情報にタッチしない ③上記を満たした上で、漫画を描くに足る情報構造を容易に組み上げること なの

2019-01-05 23:36:25
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

しかし、せっかくGithubやGitLab等があるので、そこへの接続口は構築したい。が、クロスドメイン制約を解決しないとそのままでは接続ができない。 中間サーバーを置けばできるが、ゆるくすればオープンリゾルバ的な中継鯖にもなるので危険だし、辛い。 Google Apps Scriptsは希望だがFOSSじゃない。

2019-01-05 23:41:30
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

note.golden-lucky.net/2016/05/gitgit… この感じ。いいね。これを体現できるツールであれば良いんだけど 正直見てくれなどの操作は終端フェーズなのでよい 根本は漫画を描くに値すると信じきれる構造を短時間で構築できるかという問題なので。お約束はあってもいいけど、本筋そっちのけでお約束の連続では描く意味が

2019-01-06 15:07:08
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

Gitで管理する以上、原稿が1ファイルなのではなく、複数の断片ファイルに分割されたい状態を編集できるようになるべき。そうでなければGitでの依存関係がうまく操作できない。プログラムは複数のファイルで構成されるからその状態に合わせようという安直な考えではあるけれど。

2019-01-06 15:10:11
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

エディタが1ファイルを1画面に表示しているのはエディタの都合であって、エディタが複数のファイルを1画面に表示するのはやってないだけで、できる。この断片をどうやって順番付するのかという問題はあるけれども。それも設定ファイルで持っておけばいい話。

2019-01-06 15:27:11
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

github.com/isomorphic-git… やっぱりこの辺使うしか無いのかな・・・Proxyサーバーを経由しないといけないというのが辛い。何が辛いかというと、Proxyがいつまでも存在している存在確実性と利用負荷が高くなった場合に垢バンされるのではという問題。githubが存在する限り使ってOK的な保証が欲しい。

2019-01-06 15:35:18
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

まあGitプロトコルをProxyする鯖をGoogleAppsScriptとかに書けば良いんだろうけどね。なんか深い沼地に足を踏み入れた感があるなー。でも必要なんだよ。これは。10年後もウィルスさえ居なければ動きます。あなたのマシンとアカウントで!というのは重要。

2019-01-06 15:38:46
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

さあ何から着手するか。順番としては まずwebrtcのローカルシグナリングブックマークレットを作る googleappsscriptのシグナリング鯖を作る twitterスクレイパーを作って自分のツイートデータを抜き取れるようにする それをindexeddbに突っ込む ようやくシナリオ構築ツールを作る ネーム作成機能作成へ

2019-01-07 12:59:08
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

それが済んだら、 進捗報告機能を作って 次にgit連携かな。 そしてdb暗号化対応へ 余裕があればピーヒョロロなシグナリング機能へ

2019-01-07 13:01:19
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

indexedbでやると、各タブにIDを降って、今このトランザクションID使っている人誰ー?ってメッセージングで問い合わせて、誰も居なかったら消すとかいう処理が必要になるので、ビルドシステムもないES5のprototypeチェーンも禄につかえない技術力の現場では敷居が高い。

2019-01-09 00:23:55
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

indexeddbのラッパーをnpmにくるんで外に出せた。まあなんとかですね。 テスト全然書いてないけど。 さて、これテストできるんですかね・・・いやブラウザなら分かるんだけど。 ヘッドレスChromeとかにぶん投げるのかな? もうちょっと拡張しようかな。

2019-01-09 01:42:50
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

まあちょっとdbをプロパティ指定したり、アクセっサーをシングルトン化してプロパティで呼べるように持ち回るぐらいか というかindexeddbのバルクインサートってどうやるのかなぁ api的には出来そうにないんだけど。

2019-01-09 13:01:44
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

やっぱりどう考えても、普通にリスト渡して更新するだけな気配がする。さて、トランザクション張るかなぁ・・・張れるのかなぁ・・・複数タブ上からの事実上のマルチスレッドで、張れる?1書き込みがAtomicなのは保証できるけど、其れ以上のトランザクションは貼れないよねぇ。

2019-01-10 01:41:45
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

マジでやるとなると、メッセージングAPIでタブ間、Wroker間通信をして分散トランザクションを作り込まないといけないわけだけど・・・あーでもやらないと駄目かもしれんね。複数タブ、Workerを総括実行したいとか要求もあるわけで。ウヒャーめんどくさいなぁ

2019-01-10 01:44:14
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

Indexeddbはどのタブ、Workerからも平等にアクセス可能なので、そこにトランザクションを張るとどうなる? DBMSのようにファイルシステムに無いから、 多分一度仮テーブルに入れて、コミットと同時にコピーする。しかし、当然途中で電源プッチされるとAtomic性が崩壊する。ので結局DBMS再構築だな

2019-01-10 02:04:36
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

なんだよ!其れじゃSQLiteの上に、Indexeddbの上に、車輪の再発明DBMSが乗る3階建てじゃないか・・・これは・・・アカンやつや・・・ただでさえindexeddbそんなに速くないというのに・・・

2019-01-10 02:07:26
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

と言う訳で、トランザクションを考えてみる。 まずindexeddbについてだが、こいつは1dbがロック単位となる。 ブラウザのユーザープロファイルとページのドメインで既に別れているのでdbと言いつつテーブルっぽい単位になっている。 で、未だによく理解できてないのがバージョン。1更新で1上がる

2019-01-10 12:48:03
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

このバージョンがdb単位なので、dbにロックをかけないと更新が出来ない。検索はリードコミティッドだから一応並列してできなくは無いが、Dbオープンのコストが高くてそこはよく確認できていない。多分、indexeddbのdbms接続コネクションはインスタンス単位、タブ単位だろうけど。

2019-01-10 12:53:53
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

メッセージング基盤を考えないと、テストもろくにできそうにないな。 仕様はタブ間、workerも含めてメッセージングできるようすること。 それはあるタブでユーザー操作が発生したら発行されたコマンドが連携先にもブロードキャストされること。その時、発行順番が分かること。

2019-01-10 12:59:04
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

自分の識別名を決めて、リーダーに報告して、リーダーから伝達。リーダーが順番を保持しておく。リーダーがいない時はリーダーを投票で決めると。

2019-01-10 13:01:19
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

リーダーとその他の間はMessageChannelで繋いで、切れたら残った奴らで再度リーダーを選出と。一応マルチプロセスとはいえ、同一アプリケーションなので、仕様を守っている限り、きちんと動くはず。 一番の問題は、キャッシュからブラウザのセッションが復帰した場合で、この時何処まで再現されるか

2019-01-10 22:12:44
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

このメッセージ処理の主な目的は ・マルチディスプレイ、タブでのWindow間連携、統括制御 ・マルチタブでもOKなindexeddbのトランザクション制御 ・副作用として他画面での更新検知による自動更新データリロード ・別Webサービスとのブックマークレットを介したデータ共有

2019-01-10 22:17:43
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx

js@ブラウザでやるからかなり条件はゆるいんだけど実装方法は次を考えている。 ①A起動、ブラウザ全体にpostMessageする。誰も居ないので返事なし ②B起動、Aが返事するので、Aをリーダーとみなす ③C起動、A、Bから返事、Bはリーダーを教える ④A死亡 ⑤B、CはChannel破棄で検知、Bをリーダーに

2019-01-10 22:23:11
残りを読む(52)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?