Editing Webadmin SOC2008

Jump to: navigation, search

Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to copy and paste your text into a text file and save it for later.

The administrator who locked it offered this explanation: Server migration

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
This is [[User:BugQ|bugQ]]'s proposal for [[GSoC]] 2008, which may change with the minds of those involved.
+
I intend to construct a feature-complete web-based control interface for the BZFlag server during this project. Although there already exists a Javascript/HTML [tool][] for generating config files, this, which you could call a reworking of `bzfs_conf.html`, will expand on the interface to allow other administration and configuration tasks. These include, among other things, saving the configuration on the server-side, reading and clearing logs, and controlling and checking the status of the daemon. Ideally, there would be a way to control every aspect of the server from a web browser. The primary focus in designing the interface will be ease of use, but only when not at the cost of security or portability.
  
See bugQ's development blog to check and discuss the project's progress: http://planet-soc.com/blog/89
+
An example feature lacking in `bzfs_conf.html` is the ability to edit and save the several other config-related files, like badwords and helpmsg, from within the browser. This is reasonable, since Javascript can't usually write to disk, but for this project, it's a necessity. It could be as simple as a text field, but a more sophisticated interface might be useful, such as a table of banned IP addresses with a custom input form and buttons to remove addresses from the list. Depending on the of complexity and layout of these, a separate page for the editing interface for each file might also be warranted. On the other hand, the daemon will overwrite a few files on exit for the things that can be changed by server commands, like the banlist, so a better option for those might be to let the user issue commands to the server from the web interface, which would give control over other parts of the server, as well.
  
 +
I will allow the user to choose from plugins and maps in pre-defined folders, and upload custom maps. (Although it would be interesting to do the same for plugin files, I don't think that there would be any nice way of keeping it secure.) Depending on the relative difficulty, I may either try to validate maps on upload or let BZFS check them on startup. Map uploads are actually a high priority for me, because I think that they would add a great deal of flexibility in the way one manages a BZFS. One possible offshoot of this project, for example, would be to build a BZFS farm, where registered users can create and configure their own game servers entirely through their browsers. With an interface for map uploads, this could have a noticeable impact on the BZFlag community by giving them an open creative platform.
  
==Overview==
+
As I noted earlier, security is a large concern, along with portability. For instance, Javascript has a large potential to make the interface more human-friendly, validating input, greying out dependent options, etc. -- `bzfs_conf.html` uses Javascript liberally for such purposes. However, it's likely that not every user will enable Javascript in their browsers, so in addition to validating everything on server-side, I aim to make the interface as easy to use as possible even when user scripting is not available.
'''webadmin''' will be a web-based control interface for [[BZFS]]. As opposed to the existing Javascript/HTML tool for generating config files, this interface will let the server owner control the server directly via a standard web browser.
+
  
==Design==
+
On the same note, there should be very few external tools used in this project, so that it can be deployed as widely as possible. It could be written in PHP or another common scripting language, but that would require whatever language I choose to be present on the host machine. Granted, PHP is very widely available, but since BZFlag is written in C++ already, I could write the interface in C or C++. This is the most likely outcome, because this would also allow it to be implemented as a plug-in, using the in-port HTTP feature of the BZFS API, which would make the interface more convenient to deploy. However, in order to ease development, I may use a scripting language to create a working prototype and use that as a blueprint to rewrite it in the lower-level language.
The use of a browser with a live server will allow additional administration and configuration tasks that are not available with a simple config.
+
These tasks include:
+
* Editing all config-related files
+
* Saving configuration on server-side
+
* Reading and clearing logs
+
* Controlling and checking the status of the server process.
+
+
=== Initial Limitations===
+
Optimally the tool could be developed to a point where it was able to control nearly every aspect of the server. The primary focus of this initial design interface will be ease of use and security. Portability is also a major secondary concern.
+
  
==Proposed Features==
+
As for testing, I maintain a VPS at which I could set up a public BZFS server and BZFWeb interface for others to try and give suggestions. I will also be testing each component as it is added, hopefully with BZFlag developers ensuring that my unit tests are checking for the correct behavior, and that all of the edge cases are covered.
  
=== File editing===
+
Finally, when all is done, I hope to be able to help the BZFlag team package BZFWeb along with the server distribution. I think it would improve the usability of the server, and could attract more users that were previously daunted by the process of setting up and maintaining a BZFS.
An example feature lacking in <tt>bzfs_conf.html</tt> is the ability to edit and save the several other config-related files, like badwords and helpmsg, from within the browser.
+
This is reasonable, since Javascript can't usually write to disk, but for this project, it's a necessity. It could be as simple as a text field, but a more sophisticated interface might be useful, such as a table of banned IP addresses with a custom input form and buttons to remove addresses from the list. Depending on the of complexity and layout of these, a separate page for the editing interface for each file might also be warranted. On the other hand, the daemon will overwrite a few files on exit for the things that can be changed by server commands, like the banlist, so a better option for those might be to let the user issue commands to the server from the web interface, which would give control over other parts of the server, as well.
+
 
+
=== Plugins ===
+
The user should be able to choose from plugins and maps in pre-defined folders, and upload custom maps. Depending on the relative difficulty, maps might be validated on upload or BZFS will check them on startup.  (Although it would be interesting to do the same for plugin files, there probably wouldn't be any nice way of keeping it secure.)
+
 
+
==Code==
+
Javascript will be used sparingly, in places where it makes the interface easier to use.  Since not all users allow Javascript, of course, any client-side input validation will be mirrored on the server side.  If time allows, and if it would add to the usability of the tool in certain areas, some use of asynchronus Javascript messages through XMLHttpRequest might be explored.  However, the entire interface must lose no functionality where user scripting is unavailable.
+
 
+
There should also be very few external tools used in this project, so that it can be deployed as widely as possible. It could be written in PHP or another common scripting language, but that would require whatever language chosen to be present on the host machine.  Since BZFlag itself is written in C++, using that language would eliminate the dependency.  It would also allow the admin interface to be implemented as a plug-in, using the in-port HTTP feature of the BZFS API, which would likely make it more convenient to deploy.  However, in order to ease development, a scripting language may be used to create a working prototype which would then be a blueprint to rewrite the tool in C++.
+
 
+
==Development==
+
[[User:BugQ|BugQ]] will be carrying out tests on the config files generated by the tool as well as hosting a test server for others to try and give comments on.  Suggestions on unnecessary or possible new features should be added to the talk page.
+
 
+
[[Category: Summer Of Code 2008]]
+

Please note that all contributions to BZFlagWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BZFlagWiki:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)