From: "Tomas Radej" <tradej(a)redhat.com&gt; To: "General DevAssistant discussion" <devassistant(a)lists.fedoraproject.org&gt; Sent: Friday, September 4, 2015 6:33:56 PM Subject: DevAssistant Client/Server—Resulting Architecture Howdy, all friends of DevAssistant. After a thorough deliberation and countless meetings, we have established how the final layout of DevAssistant will look like. It will be much simpler than my original suggestion from April [1], allowing only one instance of the DA server running at a time on one machine, but the security or backwards compatibility with existing assistants will not be compromised. The core of the design is the server, which will be a simple service containing the current DA logic, listening on a UNIX socket (in case you're running DA locally) or a web socket (for when the Server is in a container, a virtual machine, or even a remote machine). By connecting to that socket, a client will be able to communicate with the server through a JSON API. This API is in the works, and will cater to all sorts of clients—CLI, GUI, Web, plugins for IDEs etc.—while staying sane, i. e. the CLI client will be able to request detailed info of an assistant without receiving a PNG icon with it. On the other hand, a GUI client will make good use of it. The specification of the first version of the API will be out in a matter of days, so stay tuned. Bear in mind, though, that if you run DA remotely, the server will only be able to modify the environment of the remote machine, and not the one where the client is running, unless it's exactly the same machine. You'll then have to mount a filesystem on the host into the guest if you want to do that, and in some cases (like running DA in a container), installing dependencies won't make all that much sense unless you commit the container. For Fedora 24, we'd like to have two clients that can work with the server described above: a CLI and a web client. The Web client will be a tiny webserver whose only function will be translating API calls into pretty HTML and CSS, so that you can work with it like you did with the original GTK-based GUI. We have planned to redesign the GUI for some time, and the time is now. Running "da-gui" will then open your default browser pointed to localhost:port where the web app will reside. On top of that, when the time comes, we'd like to have a couple IDE plugins, like for Eclipse or other, but at the moment we don't have the time and manpower to make that happen. Of course, the client/server transition has security implications. We already have concrete solutions for some use cases and an outline for others. In local deployment, the immediate communication between the server and clients will be made through a UNIX socket, which is basically a special kind of file. With DA, only the current user will be granted permissions to the file, making a outside attack unlikely. We're also considering using SELinux for added security even in the context of a single user. For the web client, we'll most likely use TLS. If the clients connect to the remote server (in a container, VM etc.), TLS is in any case a must. Even with this general direction set, we welcome feedback and critique so that we can make DevAssistant more useful for all of us in the community, so please let us know if you think something could be done better or if you want to do it :) . Cheers, Tomas [1] https://lists.fedoraproject.org/pipermail/devassistant/2015-April/000065.... -- Tomas Radej

Howdy, all friends of DevAssistant. After a thorough deliberation and countless meetings, we have established how the final layout of DevAssistant will look like. It will be much simpler than my original suggestion from April [1], allowing only one instance of the DA server running at a time on one machine, but the security or backwards compatibility with existing assistants will not be compromised. The core of the design is the server, which will be a simple service containing the current DA logic, listening on a UNIX socket (in case you're running DA locally) or a web socket (for when the Server is in a container, a virtual machine, or even a remote machine). By connecting to that socket, a client will be able to communicate with the server through a JSON API. This API is in the works, and will cater to all sorts of clients—CLI, GUI, Web, plugins for IDEs etc.—while staying sane, i. e. the CLI client will be able to request detailed info of an assistant without receiving a PNG icon with it. On the other hand, a GUI client will make good use of it. The specification of the first version of the API will be out in a matter of days, so stay tuned. Bear in mind, though, that if you run DA remotely, the server will only be able to modify the environment of the remote machine, and not the one where the client is running, unless it's exactly the same machine. You'll then have to mount a filesystem on the host into the guest if you want to do that, and in some cases (like running DA in a container), installing dependencies won't make all that much sense unless you commit the container. For Fedora 24, we'd like to have two clients that can work with the server described above: a CLI and a web client. The Web client will be a tiny webserver whose only function will be translating API calls into pretty HTML and CSS, so that you can work with it like you did with the original GTK-based GUI. We have planned to redesign the GUI for some time, and the time is now. Running "da-gui" will then open your default browser pointed to localhost:port where the web app will reside. On top of that, when the time comes, we'd like to have a couple IDE plugins, like for Eclipse or other, but at the moment we don't have the time and manpower to make that happen. Of course, the client/server transition has security implications. We already have concrete solutions for some use cases and an outline for others. In local deployment, the immediate communication between the server and clients will be made through a UNIX socket, which is basically a special kind of file. With DA, only the current user will be granted permissions to the file, making a outside attack unlikely. We're also considering using SELinux for added security even in the context of a single user. For the web client, we'll most likely use TLS. If the clients connect to the remote server (in a container, VM etc.), TLS is in any case a must. Even with this general direction set, we welcome feedback and critique so that we can make DevAssistant more useful for all of us in the community, so please let us know if you think something could be done better or if you want to do it :) . Cheers, Tomas [1] https://lists.fedoraproject.org/pipermail/devassistant/2015-April/000065....