Light weight features:
o Adding "Restart Kamajii" and "Stop Kamajii" options to the GUI.
o Improving relative user path support - At the moment, we support relative user paths (path to the user directory where user.key, user.xml and sites directory reside), by simply counting on the fact that kam_conf.pl (the configuration script), and kamajii.pl (kamajii's main module) both run from the $KAMAJII_ROOT under which, all 'relative user path' directories should reside. However a problem may occur if someone chooses not to use the GUI, and instead, run kamajii.pl directly from the command line from a different current_directory than the directory the $KAMAJII_ROOT points to.
o Validating appearance tag in the site configuration files – We currently don't validate this tag (which should get as values only a number or the strings 'list' or 'uniq_list'). This validation should be added in the next version.
o Opening a password popup window when Kamajii starts, instead of opening a command line window.
o Using friendlier user messages – e.g. in case the HTTP request fails, reporting the type of HTTP error, instead of just typing the HTTP error code (report: 500 – Internal Server Error, instead of just reporting 500).
o Adding a parameter that defines whether or not to split long SMS messages.
o Adding an option of sending a test message, just to check that Kamajii Messenger works fine.
o Improving the GUI user screen, so it would be possible to view a long list of sites (by using prev, next buttons, or by using scrolling).
o Upgrading the table page parameter so that it can go over columns as well, and not only over rows. This can be useful in a Toto guess where the table is upside-down in a way:
The first row is composed of the games indices: 1,2,3,4,5... 16
whereas the second row represents the games' results: 1,x,2,1,1,1,x,2,1...
At the current version we can only go over one line at a time, but it is obvious that in this case we would like to go over the columns in order to tell the user what game ended with what result.
o Adding an option to create sites through the CGI. Maybe also adding an option to upload sites that were created by the GUI, or 'contributed' to our web site. We should keep in mind though, that such options might pose security risks.
o Adding an additional output destination: a popup window that informs the user of a new message.
o Supporting additional multi-list behavior for content and URL tags – Currently, if we have more than one list referenced in the URL or content tag, we assume them to be of the same length (size N), and run N queries, first query with A0 and B0, second query with A1 and B1 etc. This is good for scenarios of a list of users and a list of passwords, however there may be other scenarios in which we would like to use a matrix or other multi-list behaviors. A typical matrix scenario might be:
A is a list of users, and B is a list of actions to do. We want all users in A to run all the actions in B.
Heavy weight features:
Implementing the recording mechanism - Instead of learning the site definition language, the user of Kamajii through this feature, will have an option to browse the site himself and record his actions. The configuration file will be generated for him automatically. Future developers may find this web site http://www.research.att.com/~hpk/wsp/ useful for the implementation.
Handling (at least some of the functionality of) Java Script – We only deal with parsing HTML content at the moment, so sites which use Java Script pose some sort of a problem for us. A full support of Java Script is not so straight forward, but at least a partial support can be implemented.