Key words in this article: install the program in the database. The database is directly used as the backend hosting program, and the document database manager is directly used as the cloud file storage program. No backend webapp. Develop webapp on the web
about a long time ago, I began to give up the effort to unify distributed applications and local programs for the same appstack. There seems to be a natural gap between the two, which is determined by the way applications are used, this kind of artificial boundary is not used to cross. For example, web, as a distributed architecture and distributed appstack architecture, cannot be as flexible as local GUI programs or hardware acceleration programs, for example, the web emphasizes that everything is rendered on the broswer side, which leads to the need to use such things as html5,webgl,js and css html to enhance it, so that it can be slightly like a local program, one example is the WEBGAME implemented by WEB-this efficiency is completely different from the game implemented by local hardware acceleration, and the experience of WEBGAME is similar to that of traditional PC games, because the hardware acceleration cannot be implemented remotely, the stream can be sent to the local device. The web uses http instead of native tcpip on the server, which requires websocket to do things that are easy to do like native TCPIP push. Of course, there are many differences.
This is not the fault of the WEB. The WEB was initially defined like this: it was originally an ecosystem of advanced native tcpip programs. Its interface is PAGEUI, and PAGEUI is an application layer rendering. On the server side, WEB programs are mostly backend by such things as LAMP and LNMP. Such programs themselves, in fact, it is a common TCPIP program, not a basic component of a WEBOS, just like the native program's interface mechanism of task mechanism in traditional OS implementation. That is to say, all the WEBAPP are backend of, is the lamp in the amp, etc. They build a distributed appstack and define an appmodel in the form of servers. Therefore, in history, things like WEBAPP and WEBOS are not pure,- WEBAPP is a stack ecosystem built by using limited technologies in the native interface. Therefore, WEBOS is also an advanced OS on the OS-WEBOS does not exist.
We talked about a similar concept in "Installing chrome on tinycolinux": chromeos cannot be separated from the technical essence of the Native Interface (X11,GDI) and a browser, in fact, it cannot be compared with the really serious OS engineering class. An APP management interface like Qunhui can be called webos. For example, owncloud and standstorm: sandstorm has more xaas than oc.
As a component of cloud computing that defines APPSTACK, web is of great significance. Programs in cloud computing are nothing more than WEB programs. Therefore, cloud, in addition to virtualization, in the APP ecosystem, in fact, it still has nothing of its own. It is still the BS-based advanced native distributed programs.
So, will there be a breakthrough in all this? One day, the WEB also has something that does not depend on the traditional BS architecture at all? Become like a truly independent application ecosystem composed of new things? And cloudwall may be another kind of "webapp": cloudwall does propose many new and refreshing things, although it is still oriented to WEBAPP, however, some parts of it can be used as parts that are totally different from traditional WEB to generate new scrutiny. for example, its nobackend design also has its slogan to hit the point: cloudwall,an Operating system for noBackend webapps. As it said, it even proposed a new webapp and webappstack,webos prototype-changed most of the traditional webapps.
cloudwall in couchdb:the only backend as webos part
first, it uses apache couchdb, a documented database that is directly integrated with the WEB. If we call the APPSTACK we are going to talk about next as the appstack of a WEBOS, couchdb defines the unique backend of the appstack, which eliminates the need for lnmp as the backend: this is its unique feature that supports its obvious difference from some components of lnmp: This DB is document-type and nobackend.
couchdb support direct hosting app and run, called couchdb-hosted webapp, it with a similar database manager something natural is a class OC cloud storage program, support various cluchdb plug-in development, this is the whole webapp cloudwall is such a couchdb manager.
CloudWall is a kind of offline-ready toy in-browser OS, for authoring, storing, and sharing docs and CouchDB-hosted webapps. CloudWall installs via replication and needs only CouchDB and modern HTML5-compliant browser to run. Also CloudWall can run on static hosting, as a set of files.
All CloudWall components run in a browser tab, no server or even internet connection required after system started. Any local DB can eventually sync with external CouchDB instances over http(s). One CouchDB can have several users connected, thus providing shared workspace, docs and applications set.
In my the appstack series of the app series series in the article, I had been looking for cloud storage program selection, we changed the mongdb,postgres, this procedure selection actually big talk is WEBOS, we have put forward such attempts and assumptions in these articles.
Let's take a look at the design of this kind of OS: Does an app have a stack? If the stack is enlarged to be directly supported by WEBOS, the OS technology behind this cloud program will become clear:
in fact, when considering that an app needs to be equipped with an appstack, the limitations that it relies on the native application appstack to define its own new appstack can never be avoided, because the mongdb,postgres is always regarded as the dbbackend part of the appstack, and webapp should not have obvious backend: like nativeapp stack, they should be integrated into a webos and solved in advance.
couchdb uses the database management system to directly manage and store WEBAPP (of course, it can also directly manage static files for cloud storage like other document databases), if couchdb is used as the whole webos like cloudwall, the traditional webapp development is defined in this webos. The four appstack components of cloudwall are integrated into the webos concept called cloudwall OS.
GDI:Renders HTML and receives user interactions
App runtime:Manages bindings between data and UI controls
CloudWall:Prepares, runs and closes apps, manages app switch
Storage:Stores apps and documents, optionally syncs with external CouchDB instances
however, this kind of development has made the development of webapp become the same as that of the local app (there is no need to deal with the part of the appstack but only need to pay attention to the things in the app). We have been hoping for the following results: webapp uses file storage as the backend like local applications, and this goal is also achieved.
inapp editor in cloudwall: language and development
in all the efforts of "bcxszy series", I want to get such a program and development method: without changing the large scale of native programs and webapp, making WEB programs as simple as local programs, in this way, the concept of local program/webapp development can be shared. In terms of fuzzy appstack, this is mentioned in couchdb in cloudwall and has been solved. Here we will talk about the parts related to language development:
it can be said that in all the efforts of bcxszy series, I also want to promote such a program and development method: Source code is a file, which can be packaged everywhere and developed directly per app an ide, this is extremely convenient for both practical and development and self-learning programming.
Fortunately, WEBAPP src textualization and support for lightweight take-away inplace editor are the natural advantages of all WEB programs. Although WEB programs are different from local programs at the beginning, WEB standardization, HTML standardization, JS language standardization is actually a joint effort to make the WEB ecosystem close to the local ecosystem. For example, one of the efforts of JS is nativejs:reactos.
In fact, another aspect of the tight combination of couchdb and web is js, which is an enhancement agent that can truly bring the integration of naitveapp and webapp, making cloudwall support the extremely convenient inappeditor, in this way, the development of the plug-in supported by cloudwall is the webapp developed under cloudwall webos, which supports using couchdb to directly store and save files during app development.
In this way, personalcloud should be the argument of web OS. The development experience is the same as that of local development, and even simpler. When the two concepts above cloudwall are no longer limited to bs development, it can be a new generation of WEBOS.
This article can be used to enrich the unfinished part of the web of "programming practice selection", and the idea of the whole article can be used as the practical part of part 2 of "bcxszy. If the concept of cloudwall is used, appstack and apps can be integrated into apps in the future.
(There is no reply here, scan the code to WeChat to participate in the message, or directly click to the original text)