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".
Aš pritariu idėjai apie didesnę abstrakciją ir funkcionalumą, taip pat turėti visą išmanųjį telefoną kaip duomenų bazę. Esu įsitikinęs, kad dabartinės „Android“ API jau leidžia tam tikram tikslui priartėti, bet (galbūt) ne taip paprasta, kaip pateikti užklausą duomenų bazėje.
Iš esmės, ko norite, yra programų su OS savininko tapatybe skaidrumas iki privačių programų metodų ir saugojimo, bet ne su kitomis programomis be aiškaus leidimo ir ne kitų tapatybių (pvz., Pardavėjo, kuris galbūt įdiegė 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).
Programos turėtų būti distiliuotos pagal užklausų planus. Yra užklausų planas, kuriame pateikiamos visos programos pateikiamos užklausos ir santykinis kiekvieno tipo užklausų dažnis.
Žmonės galėjo suprojektuoti visas programos sąveikas - visus ekranus, kuriuose rodomi duomenys arba kurie leidžia duomenis keisti. Tada užklausų planavimo priemonė gali sukurti efektyvią programą iki atskirų užklausų, naudojamų duomenų išdėstymui.
Leiskite kompiuteriams išdėstyti duomenis mums.
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.
Skambinkite jiems „APP PLAN“.
Programų planuose yra sąsajos ekranų sąrašas ..... ir ekrane rodomi arba keičiami duomenų laukai.
Programų planuose taip pat nurodomas vidinės programos integravimo API, kuris bus naudojamas su ekrane rodomais duomenimis. Taigi būtų skambučio API. ir skambučio API ima skaitmeninį lauką, kuris yra telefono numeris, galite prijungti skambučio API naudodami lauką ekrane
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
Užklausų planuotojai duomenų bazėje nustato, kaip efektyviai vykdyti užklausas, atsižvelgdami į tai, kiek eilučių yra ir indeksų, kuriuos reikia ieškoti. Programų planuose nustatoma, kaip efektyviai išsiaiškinti, kaip įdiegti programas.
Gaunant duomenis programų planavimo priemonė atsižvelgs į šiuos dalykus:
Kaip sukurti vartotojo sąsają iš duomenų struktūros:
Duomenų bazėje duomenys gali būti saugomi kaip medis, grafikas ar matrica. Kaip vartotojui suprantamu būdu pateikti šią informaciją? Programų planavimo priemonė naudos tam tikras euristines savybes, kad generuotų vartotojo sąsajas su skirtukais, sąrašais ir turtingu elementų atvaizdavimu. Šiek tiek panašūs į django administratoriaus ekranus.
Planuotojas turėtų įtraukti įvairius įgūdžius į skaičiuojamą ekspertų sistemą, pvz., Prieinamumo reikalavimus, sukurti efektyvias pakartojamas užduotis.
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.
Įdomu tai, kad beveik bet kuri programa yra tik susijusių objektų su modifikavimo taisyklėmis išdėstymas. Galima įsivaizduoti, kad yra kažkas panašaus į „nuo programos nepriklausomus objektus“ (AIRO), kurie kartu elgiasi kaip programa, bet nėra programa, veikiau yra laisvi objektai su savo nepriklausomomis tapatybėmis ir vietomis adresų erdvėse.
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.