Do we need a server GUI?

[mdgilene]

So currently all of the GUI work has been focused on the client side. But I think we should determine if we need or want a server side GUI as well.

Possible Features

• Monitor status of the server.
  • Who's connected
  • Log of modifications made to files
• Act as a client itself.
  • The server GUI would have all the same features of the client GUI without having to connect with a separate client.
• Maintain a list of authorized users
• Change server settings ie. Maximum client connections at a time

This is just a few that I've been able to come up with quickly but I'm sure there is much more that could be done.

Not only would a server side GUI make the interface more user friendly, but I think it would make it easier to debug. Allowing us to directly view what is going on with files/users/commands rather than reading through a log in a terminal.

This could help alleviate another issue that I noticed with the teams before us. Last semester both Teams 3 and 6 were focusing on the GUI for the client. However they both had 2 relatively different designs. With the addition of a server side GUI we would no longer have 2 teams working on the same thing but rather one would work on the client and one on the server.

[rsanchez-wsu]

I am personally not a big fan of server-side GUIs, but I am not opposed to it in this case. Depending on what you come up with, it might be bigger than what can be covered reasonably under a single issue. You may also want to consider creating a wiki page that acts as the specification based on the comments from this issue and considering that wiki page as your deliverable for this issue. New issues would then be created based on the spec in the wiki page to drive the individual feature implementations.

[LoganRickert]

A server GUI would primarily provide benefits to people who are testing their parts and I think that the points you brought up are valid. My only thing is that I personally think the server still needs a lot more foundation work before any work on a GUI begins.

[mdgilene]

True that if the server was a much more complex system then a GUI would be far more beneficial than it is now. But even now it could be as simple as open up a stylized terminal where the output from the server is put. Which wouldn't take much or long to implement. Then as more and more functionality and complexity is added to the server then you can add interfaces to those systems to the GUI.

[rsanchez-wsu]

@mdgilene If you are willing to tackle it, I won't stop you. I like the suggestion to start small and simple and grow it from there.

[mdgilene]

I can try to write up a wiki page that would layout the specifications for it. Although I would probably wait until we are closer to cleaning up the remaining issues and such from last semester before beginning any real work on it.

[mdgilene]

I have written up a preliminary wiki page regarding this issue.

https://github.com/rsanchez-wsu/jfiles/wiki/Server-Gui

[rsanchez-wsu]

@mdgilene Thanks for starting the wiki page. I hope that others decide to chime in and offer their suggestions.

[LoganRickert]

I think a few things could be added and change to improve the current graphical user interface laid out.

• Adding a 'stop' and 'restart' button.
• Split the main section in two. The bottom half be the console output and the top half be current stats on the server. Things like:
  • How many current active connections
  • Current bandwidth usage / how many files are currently in transit.
  • A graph of average connections per some time period
  • A list of currently connected clients and a button to 'disconnect' / 'ban' the client.
• Configuration expansion:
  • Max bytes/s per client
  • Max bandwidth per time per client
  • Enable / Disable anonymous file transfer
  • Default commands a user can run
  • Default commands an anon can run.
  • Max number of commands per time per user
• Account configuration
  • Create / Delete
  • Raise account privilege (from user to admin, etc).
  • Set default directory and restrict from going up with user, etc.

Just a few ideas. Some are more out-of-scope but I figured maybe one day some may be reachable.

[rsanchez-wsu]

@LoganRickert I think those are all viable ideas. Your top level points at least should be turned into their own issues.

[mdgilene]

I agree all of those things would be good to have a some point. At the moment though I was simply looking to get something up and running that is able to accomplish the same things as the server itself. Currently the server doesn't have an interface to may of those things so we would have to wait for those to be implemented before we can create a UI element for them.