DevAssistant Client/Server—Resulting Architecture

[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.html

-- 
Tomas Radej