This wiki is archived and useful information is being migrated to the main bzflag.org website

Difference between revisions of "Webadmin SOC2008"

From BZFlagWiki
Jump to: navigation, search
m (little fixes)
Line 4: Line 4:
  
 
==Overview==
 
==Overview==
BZFWeb isbe a web-based control interface for [[BZFS]].  s opposed to the existing Javascript/HTML [https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/misc/bzfs_conf.html tool] for generating config files, this interface will let the server owner control the server directly via a standard web browser.
+
BZFWeb will be a web-based control interface for [[BZFS]].  As opposed to the existing Javascript/HTML [https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/misc/bzfs_conf.html tool] for generating config files, this interface will let the server owner control the server directly via a standard web browser.
  
 
==Design==
 
==Design==
Line 19: Line 19:
  
 
=== File editing===
 
=== File editing===
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.  
+
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.
 
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.
  

Revision as of 23:05, 25 April 2008

This is bugQ's proposal for GSoC 2008.

Picture Frame.png This page contains the design document for an enhancement or feature. It is a work of collaborative development, and may not represent the final design. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design.


Overview

BZFWeb 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

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;

  • Saving the configuration on the 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

File editing

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.

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

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.