Mindey, 
Appless OS
Operating system without user-facing apps!
Today, pretty much all operating systems allow installation of apps. However, apps share basic functionalities, for example, there is a plethora of calling apps, messaging apps, payment apps, drawing apps, etc. etc. etc.
Since all that people really need is the functionality and data, not the apps per se, "Appless OS" virtualizes all the apps and runs them in virtual containers under the hood, and has drivers to emulate the user, and virtualization layers, that provides the functionality of the apps via drivers framework (like "Metadrive") that drives apps, rather than exposing user to interact with them manually, collects and organizes the data from those apps, and provides it for the user in a unified interface, that implements viewer for items with arbitrary properties as generalized:
- Lists
- Matrices
- Trees
- Graphs
The "Appless Merge OS / DB" would introduce a high level programming language and a unified API, that allows user to have true ownership of their OS. Instead of "OS" as a framework for apps, it is just an "easily programmable OS, that takes care of being a good DB of everything on it".
スマートフォン全体をデータベースとして持つことは素晴らしいことであるだけでなく、より優れた抽象化と機能第一の考え方のアイデアを歓迎します。現在のAndroidAPIは、それに近づく何かをすでに許可していると確信していますが、（おそらく）データベースにクエリを実行するほど単純ではありません。
基本的に、必要なのは、アプリのプライベートメソッドとストレージまでのOS所有者IDを持つアプリの透過性ですが、明示的な許可のない他のアプリや、他のID（ベンダーのIDなど、 OS）。
I welcome the idea of greater abstraction, and functionality first mindset, as well as having entire smart phone as a database is nice. I'm sure the current Android APIs already allow something approaching that, but (perhaps) not as simply as querying a database.
Basically, what you want is the transparency of apps with the OS owner identity up to the private methods and storage of the apps, but not with other apps without explicit permission, and not other identities (like that of vendor, who may have installed the OS).
プランをクエリするには、アプリを抽出する必要があります。アプリが行うすべてのクエリと、各タイプのクエリの相対頻度を表すクエリプランがあります。
人々はアプリのすべての相互作用を設計することができます-データを表示したり、データを変更できるようにするすべての画面。次に、クエリプランナーは、データのレイアウトに使用される個々のクエリに至るまで、効率的なアプリを生成できます。
コンピューターにデータをレイアウトさせましょう。
Apps should be distilled to query plans. There is a query plan that represents all the queries that an app makes and the relative frequency of each type of query.
People could design all the interactions of an app -- all the screens that show data or allow data to be modified. Then the query planner can generate an efficient app, down to the individual queries used to the layout of data.
Let's let computers layout data for us.
それらをAPPプランと呼びます。
アプリプランには、UI画面のリストと、画面に表示または変更可能なデータのフィールドが含まれています。
アプリプランでは、画面に表示されているデータで使用するバックエンド統合APIも指定しています。したがって、呼び出しAPIがあります。呼び出しAPIは、電話番号である数値フィールドを入力として受け取ります。呼び出しAPIを画面上のフィールドに接続できます。
Call them APP PLANS.
App plans contains a list of UI screens.....and the fields of data that is displayed or modifiable on the screen.
App plans also specify the backend integration API to be used with the data that is on the screen. So there would be a call API. and the call API takes a numeric field as input which is the phone number, you can wire up the call API with the field on the screen
データベースのクエリプランナーは、行数と参照する必要のあるインデックスに基づいて、クエリを効率的に実行する方法を検討します。アプリプランは、アプリの実装方法を効率的に解決する方法を決定します。
アプリプランナーは、データを取得するときに次のことを考慮します。
-インターフェースを表示するために取得する必要のあるデータ -サーバーに対して行われたクエリを構造化する方法-クエリを送信するか、クエリ名を送信しますか？ -表示する前のデータの変換。
データ構造からUIを生成する方法：
データベースは、データをツリー、グラフ、またはマトリックスとして保存する場合があります。この情報をユーザーが理解できる方法で表示するにはどうすればよいですか？アプリプランナーは、いくつかのヒューリスティックを使用して、タブ、リスト、およびアイテムの豊富なレンダリングを備えたUIを生成します。 django管理画面に少し似ています。
計画担当者は、アクセシビリティ要件などの計算可能なエキスパートシステムにさまざまなスキルを取り入れ、効率的な反復可能なタスクを作成する必要があります。
Query planners in database work out how to efficiently execute queries based on how many rows there are and the indexes that need to be consulted. App plans work out how to efficiently work out how to implement apps.
The app planner will consider the following things when retrieving data:
How to generate a UI from a data structure:
The database might store the data as a tree, graph or matrix. How to surface this information in a user understandable way? The app planner will use some heuristics to generate UIs with tabs, and lists and rich rendering of items. A bit like django admin screens.
The planner should capture various skills into a computable expert system such as accessibility requirements, create efficient repeatable tasks.
ほとんどすべてのアプリケーションは、変更ルールを使用したタイプの関連オブジェクトの配置にすぎないことを考慮するのは興味深いことです。 「アプリケーションに依存しない関連オブジェクト」（AIRO）のようなものを想像することができます。これは、組み合わせてアプリケーションのように動作しますが、アプリケーションではなく、アドレス空間に独立したIDと場所を持つ無料のオブジェクトです。
It is interesting to consider, that pretty much any application is just an arrangement of related objects of types with modification rules. One could imagine having something like "Application-Independent-Related Objects" (AIRO), that in combination behaves like an application, but are not an application, but rather are free objects with their independent identities and locations in address spaces.