4 ms·

Your ideas resonate a lot with dependency injection [1] to me. However, I don't see how such an "App manager" would be able to setup, for instance, an nginx ser

Your ideas resonate a lot with dependency injection [1] to me. However, I don't see how such an "App manager" would be able to setup, for instance, an nginx server with multiple virtual hosts. Some applications need entire configuration languages because they are so flexible that writing some ini/json/xml quickly becomes too cumbersome. How would your system deal with those problems? Finally, your proposed solution seems to suffer from having to adapt all applications to be able to manage them. This is impractical to say the least, and if you had the resources to take that adventure... I think you'd be better off turning to something like Nix https://en.wikipedia.org/wiki/Dependency_injection https://en.wikipedia.org/wiki/Dependency_injection

peterwwillis 9y ago
> I don't see how such an "App manager" would be able to setup, for instance, an nginx server with multiple virtual hosts #!/usr/bin/perl -w require App_Manager; app_provides("service", "nginx", "config", "test.com", "server { root $APP_HTML_DIR; index index.html index.htm index.nginx-debian.html; server_name test.com www.test.com; location / {try_files $uri $uri/ =404;}}" app_provides("service", "nginx", "config", "example.com", "server { root $APP_HTML_DIR; index index.html index.htm index.nginx-debian.html; server_name example.com www.example.com; location / {try_files $uri $uri/ =404;}}" app_wants("service", "inet", "http", "{ tcp port http ; tcp6 port http }", "acceptable_providers { nginx; }") app_wants("service", "inet", "http", "nginx") This is a dumb example, but illustrates one way this could happen. The actual CM in the background that the App_Manager library connects to would take these config directives and communicate with the other software (nginx) in order to set it up how the app above has specified. Ideally the above would not include an Nginx-specific configuration, but one that was more abstract, to allow any HTTP service to provide for the needs of the application. That's probably wishful thinking. But on the other hand, there are probably millions of examples of an application needing an HTTP server in extremely similar ways, so maybe service-specific configuration specifications aren't totally insane. > Some applications need entire configuration languages because they are so flexible that writing some ini/json/xml quickly becomes too cumbersome. How would your system deal with those problems? You can abstract away almost all of the details of an automated system. They're just not built today with this in mind. Systems today are built as isolated islands of complexity and depend on humans to teach them how to shake hands. This is largely not necessary, but it is with how people are currently managing systems. > Finally, your proposed solution seems to suffer from having to adapt all applications to be able to manage them In the same way that networked applications "suffer" from adapting a standard protocol. Another example: #!/usr/bin/perl use DBI; $dsn = "dbi:SQLite:dbname=$dbfile"; $dbh = DBI->connect($dsn, $user, $password); $sql = 'CREATE TABLE people (id INTEGER PRIMARY KEY, fname VARCHAR(100), lname VARCHAR(100), email VARCHAR(100) UNIQUE NOT NULL, password VARCHAR(20))'; $dbh->do($sql); But this looks complicated; I guess asking apps to suffer under the concept of a standard interface and language will never catch on.

peterwwillis 9y ago

> I don't see how such an "App manager" would be able to setup, for instance, an nginx server with multiple virtual hosts #!/usr/bin/perl -w require App_Manager; app_provides("service", "nginx", "config", "test.com", "server { root $APP_HTML_DIR; index index.html index.htm index.nginx-debian.html; server_name test.com www.test.com; location / {try_files $uri $uri/ =404;}}" app_provides("service", "nginx", "config", "example.com", "server { root $APP_HTML_DIR; index index.html index.htm index.nginx-debian.html; server_name example.com www.example.com; location / {try_files $uri $uri/ =404;}}" app_wants("service", "inet", "http", "{ tcp port http ; tcp6 port http }", "acceptable_providers { nginx; }") app_wants("service", "inet", "http", "nginx") This is a dumb example, but illustrates one way this could happen. The actual CM in the background that the App_Manager library connects to would take these config directives and communicate with the other software (nginx) in order to set it up how the app above has specified. Ideally the above would not include an Nginx-specific configuration, but one that was more abstract, to allow any HTTP service to provide for the needs of the application. That's probably wishful thinking. But on the other hand, there are probably millions of examples of an application needing an HTTP server in extremely similar ways, so maybe service-specific configuration specifications aren't totally insane. > Some applications need entire configuration languages because they are so flexible that writing some ini/json/xml quickly becomes too cumbersome. How would your system deal with those problems? You can abstract away almost all of the details of an automated system. They're just not built today with this in mind. Systems today are built as isolated islands of complexity and depend on humans to teach them how to shake hands. This is largely not necessary, but it is with how people are currently managing systems. > Finally, your proposed solution seems to suffer from having to adapt all applications to be able to manage them In the same way that networked applications "suffer" from adapting a standard protocol. Another example: #!/usr/bin/perl use DBI; $dsn = "dbi:SQLite:dbname=$dbfile"; $dbh = DBI->connect($dsn, $user, $password); $sql = 'CREATE TABLE people (id INTEGER PRIMARY KEY, fname VARCHAR(100), lname VARCHAR(100), email VARCHAR(100) UNIQUE NOT NULL, password VARCHAR(20))'; $dbh->do($sql); But this looks complicated; I guess asking apps to suffer under the concept of a standard interface and language will never catch on.