Going client/server

Tomas Radej tradej at redhat.com
Thu Apr 30 12:50:32 UTC 2015


On 30/04/15 11:17, Miro Hrončok wrote:
>
> Thanks Tomáš for explaining everything, I think I understand it much
> better now.

Any time.

>>> How does this works on non-Linux platforms than?
>>
>> DA server (i. e. webserver, bridge, service, agent) runs in a virtual
>> machine or in a container. It is my impression that supporting OS X is
>> quite hard with the current architecture, and Windows is next to
>> impossible.
>>
>> By moving DevAssistant to a more constrained, virtualised environment,
>> it will be much easier to support more complex use cases - e. g.
>> inheritable container support for *all* "create" projects. Furthermore,
>> the only part running on the host system will be the client. With WebUI,
>> supporting OS X or Windows would be dead easy, because all the changes
>> would be done inside the VM.
>>
>> As for how would DA be distributed then, I am thinking a pre-made
>> virtual image of sorts with DA fully set-up. In any case, we can't help
>> Windows users set up virtualisation, so they'll have to do some work
>> anyway. If we decide to go this way, they'll only need to install a
>> virtualisation host, run the image, and connect to IP:Port from their
>> browser.
>>
>> This sort of limits the usage on non-Linux platforms, but I believe that
>> encouraging the use of virtualised environments is something we should do.
>
> One thing I don't understand, when I run DA on Windows/Mac int this way,
> and I create let's say a new Django project using the WebUI, it's
> created in the VM. How do I develop something in this project than? I
> hope not using some text editor inside the VM, because frankly, if I do
> that I could have just easily install Fedora into a VM and run DA as it
> is today.
>
> Do I get my source code mounted? Or something else?

Mounting directories is the plan, yes. I assume a considerable part of 
getting DA running in such a setup will have to be solved through 
documentation, but it is my estimate that it's still significantly less 
work for the user than if done any other way.

> How do I run ./manage.py runserver and such?

Good question. One way that crossed my mind is having generic assistants 
that just wrap said invocation. Another is making sure sshd is running 
and just telling the user to SSH into the VM/container.

The third, currently rather hypothetical way, is automatically 
generating custom assistants for these actions and storing them in the 
source tree of the project, where they'll be automatically picked up by 
DevAssistant. It is my plan to push for custom (mostly prep and tweak) 
assistants stored in source trees rather than DAPs only, because it 
improves the acceptance of assistants through reduced workload for the 
developer.

If you (or anyone else) have a better idea how to do this, lay it on me, 
please.

TR


More information about the devassistant mailing list