1:53 a.m.
Hi Miro,
sorry for the late response.
Generally, I'm not against simplifying the architecture that Tomas proposed, but I see
a problem with your idea.
In the proposed architecture, it should be possible to deploy DA to a company server,
where all developers of the given company would use it. In your proposal, this would mean
running a DA server instance for every developer - this could be very costly (in terms of
HW resources). In Tomas's proposal, this only means running one DA server instance and
spinning bridge instances on demand.
I talked to Tomas and he said that he'd incorporate some of your thoughts into his
proposal. So let's wait for Tomas's update and then have one more round of
discussion about it.
Thanks a lot!
Slavek
----- Original Message -----
After we've discussed this with Tomáš, I'm sending my idea
about how
client-server da might look.
My idea is less robust, but it requires less components, less
communication, less code...
The idea is to only have two main components: the client and the server.
Where the client is a very thin command line client, working very much
like Tomáš have described it.
The main difference I'm proposing here is that the server contains
everything else - webserver, logic, webui, polykit agent... everything.
The server would run under "joe" - i.e. under the unprivileged user
account of the developer.
There are two main scenarios:
1) Joe wants to run da from the command line
In this case, Joe will just use da as he is using it today, when he
runs a "da something" command, da will check some magic file like
~/.devassistant/server.pid to see if the server is running or not.
* If the file does not exist, it will spawn the server [1] and save
the PID, port, etc. to that file, and client connects to it
* If the file does exist and the server is not actually running,
the file is deleted and the previous thing happens
* If the file exists and the server is running, client connects to it
(In case the server is too much resources consuming, it can
terminate itself after X minutes of inactivity, or something like that.)
2) Joe wants to use the WebUI
In this case Joe will run something like:
da server run # the exact command is not important right now
And da will do the same thing as in 1, but this time there will be
no connecting, instead a link for Joe will be printed.
It will also be possible to stop the server by something like:
da server stop
I think this proposal will work when installing form PyPI, when
installing from RPM and even when installing on a different platform
(the spawning might start the designated WM, etc.).
I see the following advantages:
* we will not need to run everything trough (client <-HTTP-> webserver
<-dbus-> bridge [<-dbus-> agent]) pipeline
* the code will be easier to implement using as much as possible from
the current code base
* the entire thing would be easier to run for the user
* no need for extra user accounts
I see the following disadvantages:
* there will be no permanent <1000 da server port, but instead new
>1000 ports will be assigned as available
* each user on a machine will get their own webserver running (but
frankly, who uses multiple user logins at the same time for developing?)
* we still need to somehow check if the user who is accessing the WebUI
is the one who launched it (but this is also the case of the previous
proposal)
[1]
http://stackoverflow.com/questions/6011235/run-a-program-from-python-and-...
_______________________________________________
devassistant mailing list
devassistant(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/devassistant
--
Regards,
Slavek Kabrda