Capsule - Single-file web apps that save data into SQLite

よくわからないな。これは特定の文脈では機能するかもしれないが、元のアイデアが意味をなす範囲を超えて一般化されすぎているように思える。

もしユーザーがこれらのウェブアプリを実行するために特定のアプリケーションをダウンロードする必要があるなら、最初からそのアプリケーションを送ればいいのではないか？同じ手間をかけて同じ結果にたどり着くのに、なぜCapsuleを使うという回り道をするのか？

もしこれがほぼ普遍的に採用されているアプリケーションなら意味があるだろう。しかしそうではなく、それに最も近いものはブラウザだ…そしてブラウザはすでにあなたが説明していることをやっているのでは？

データをアプリケーションにバンドルするのは理にかなっているが、それはごく限られた状況でのみ適切だ。もしウェブアプリと一緒にデータを配布する気があるなら、単にHTMLファイルにデータを埋め込めばいい。ユーザーがこのデータを変更することを想定しているなら、こんな風に配布したいとは思わない。

私の意見：アプリが状態を更新・保持する必要があるなら（SQLiteでも他のDBでも）、それはバンドルファイルとして配布するものではないだろう。

少なくとも、ウェブ上にホスティングするのに比べて極めて制限が多い。最近ではホスティングするのはそれほど難しくない。

ワークフローを考えてみてほしい：状態が変わるたびに、アプリを使っている他の全員に新しいCapsuleファイルをメールで送る必要がある。そして、状態は少なくとも時々は変わるはずだ。そうでなければDBを使う理由がほとんどない。

代わりにウェブ上にホスティングすれば、DBの状態は動的に更新され、アプリへのアクセス権がある人なら誰でも自動的に利用できる。その方がずっとシンプルではないか？

まさにこのアイデアに取り組んできた。sqlarを「フォーマット仕様」として使っている。ブラウザで動作し、デスクトップとAndroidではTauriを使って動作する。

https://github.com/JoshTheDerf/uapp

デモアプリとゲーム：https://thederf.com/uapp/demo/

このアイデアが大好きです！AIの普及で見られた副作用の一つ：AIは視覚的な成果物を作るのはとても得意ですが、その成果物にデータを提供する必要がある場合、ハードコードしない限り共有する良い方法がありません。

> このアプローチの欠点の一つは、複数の人が作業すると異なるコピーが作成されることです。同じファイルの異なるコピーをマージできるようにするため、各データエントリには一意のUUIDとタイムスタンプがあります。

これが最初に頭に浮かんだことです：二つのソースからの変更とそれらの調整。異なるソースからのデータ入力の扱いについての記述はありますが、それらが正確にどのように調整されるのかはわかりません。例えば、二人のユーザーが.capsuleのコピーを持っていて変更を加え、それを相手と共有したい場合、異なるデータを持つ二つの個別の.capsuleができます。

どのようにマージするのですか？

ChromiumブラウザとFilesystem API、そしてネイティブっぽい感触のためのPWAマニフェストを使えば、これの安価な近似が得られます。AIのおかげで、ブラウザネイティブの機能だけに基づいて構築することへの興味が再燃しました。

https://developer.mozilla.org/en-US/docs/Web/API/File_System...

MS Accessを思い出させる。IT部門にとっては頭痛の種になったが、リソースが限られた一部の部門内のニーズも満たしていた。

これがどこに向かうのかとても興味がある。クライアントをオープンソース化する予定ですか、それとも安定したらファイル仕様を単に公開するのですか？

キラー機能のアイデア：

作者が自分のカプセルをインターネットに公開できるようにし、それを使いたい人（ユーザーと呼ぼう）がアプリにカプセルの名前（アドレスと呼ぼう）を入力すると、あなたのプログラムがそのカプセルをユーザーのデバイスに取得するようにする。

要件：