Appless OS

+2  

Operating system without user-facing apps. Instead, exposes basic functionalities, high level programming language, API and data.

YAML 来源 想法

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".



(别通知) (可选) 请,登录

有趣的是,几乎所有应用程序都只是带有修改规则的类型相关对象的排列。可以想象有类似“与应用程序无关的对象”(AIRO)之类的东西,它们组合起来的行为就像一个应用程序,但不是应用程序,而是具有独立标识和地址空间位置的自由对象。

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.



    : kriz
    :  -- 
    :  -- 
    

Mindey,

数据库中的查询计划者可以根据行数和需要查询的索引来制定有效地执行查询的方法。应用计划确定了如何有效地制定实施应用程序的方法。

应用计划者在检索数据时将考虑以下事项:

-需要检索以显示界面的数据 -如何构造对服务器的查询-发送查询或发送查询名称? -在显示之前对数据进行转换。

如何从数据结构生成用户界面:

数据库可能将数据存储为树,图或矩阵。如何以用户易于理解的方式显示这些信息?应用计划者将使用一些启发式方法来生成带有选项卡,列表和项目丰富呈现的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:

  • data that needs to be retrieved to show the interface
  • how to structure the queries made to the server - send the query or send a query name?
  • transformations of the data before displaying.

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.



    : transiency
    :  -- 
    :  -- 
    

chronological,

称他们为APP PLANS。

应用计划包含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



    : transiency, Mindey
    :  -- 
    :  -- 
    

chronological,

应将应用程序提炼为查询计划。有一个查询计划,代表应用程序进行的所有查询以及每种查询的相对频率。

人们可以设计应用程序的所有交互-显示数据或允许修改数据的所有屏幕。然后,查询计划者可以生成高效的应用程序,直到用于数据布局的单个查询为止。

让我们让计算机为我们布置数据。

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.



    : kriz
    :  -- 
    :  -- 
    

chronological,

我欢迎更大抽象,功能优先的想法以及将整个智能手机作为数据库的想法。我敢肯定,当前的Android API已经允许一些接近该API的东西,但是(也许)不像查询数据库那样简单。

基本上,您想要的是使应用程序具有操作系统所有者身份(直到私有方法和应用程序存储)的透明性,但不与未经明确许可的其他应用程序透明,而不与其他身份(例如可能安装了操作系统的供应商的身份)透明操作系统)。

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).



    : 草长莺飞
    :  -- 
    :  -- 
    

Inyuki,

语言