Section 7.1 - Outstanding Issues Overview

Outstanding issues can results for some actual or latent defect, as well as potential improvements to the design of the system.

Section 7.2 - Destination Selection Limitations

Section 7.2.1 - Overview

When the teleporter was first delpoyed for testing, it worked perfectly well. The heartbeat would identify what type of destinations should be selected and the teleporters selected would be returned and placed in the teleporter's destination notecard. Until the next heartbeat, the teleporter used its local copy for its destination menu, keeping the comunications traffic low even if there is heavy teleporter use.

Initially, the teleporter worked as expected. However, when the number of selected to be stored in the local notecard exceed sixteen (16), the heartbeat program began failing with "index out of range" errors. at first, it was not obvious that the cause of the problem as not a logic fault, but rather a default limitation on the amount of data that could be accepted from the php script running on the HTTP server. The default limit was set at 2048 characters.

Each teleporter selected took about 128 characters to pass information back to the heartbeat script to be stored in the destination notecard. The exact size of each enty depends on variable items such as the name of the destination teleporter/location, the size of the destination location, incldung the simulator address and the region name. Investigation showed that the acceptable size of a data packet from the php script could be increased to 16,384 bytes, which would give about 128 teleporter destinations before running into the same problem. Using a common menu configuration where the display provides twelve (12) selection buttons with three (3) used for housekeeping, this would be equivalent to fourteen (14) pages to scroll through to see all possible selections.

Section 7.2.2 - Possible Mitigations & Corrections

(1) MESSAGE SIZE LIMITATIONS
The size limitation on the information packet from the php script could be totally removed by interrogting the database for each page of the menu. Although heavy use is unlikely in this environment, it is still a design goal as the teleporter has the capability to work across multiple simulators, even if there is likely to be occasional breaks in communication between the simulation and the HTTP server.

As a result, the first avenue of attack is to condense the size of the data packet required to define each teleporter.

Currently, each teleporter can be assigned a locality type which is an arbitary description, for example, "Official Services", "Entertainment" or "Accomodation". This is about an extra 20 characters per destination. If the locatiry type is restricted to a fixed set of options, this could reduce the size of this field down to two characters (00 to 99) and stil provide 100 locality type options. This would have about 15 characters on average.

If one assumes that most destinations will be located on the simulator holding the teleporter, it is redundant to send the address of the simulator. It is also likely that most of the desired teleporters will be location in the same region as the teleporter, so in most cases, the teleporter does not need to be sent either. To cover all possible locations, there also needs to be an options to send all of the information including the simulator and region name. This would require a variable format message to allow the message to be compressed where possible but alse allow a full location if necessary. The proposed message format is as follows:

Where LOCATION_NAME is the text name of the Destination, for example, "Police Station";

COORD_TYPE is the type of coordinates being used. 0 = In world, in region, 1 = In world, 2 = Out of world

LOCATION_ADDRESS_INFO is the various location address info. if COORD_TYPE = 0, <vector> of location location; 1 = REGION_NAME|<vector> of local location; and 2 = WORLD_NAME|REGION_NAME|<vector>

LOOK_AT vector is for determining which way the user should face upon landing.

LOCATION_INFORMATION determines the geographic segments where destinations should be included. This information is held in an unsigned integer and may be up to 4 digits long.

This will shorten the name significantly. Assuming a location name of 16 characters, the message for an in-region location will about 55 characters, less than half of the current format. This would bring the maximum number of entries on the notecard to about 256 locations.

(2) POTENTIAL MENU SIZE ISSUES
Even if the issues in (1) MESSAGE_SIZE LIMITATIONS are not addressed, there is still the potentila for up to 128 destinations being selected. Using the standard menu's nine (9) entries per page, that would be still be 14 pages of destinations. A potential mitigation for this would be to use the LOCATION_TYPE as a mandatory field and to break the destinations into pages based on the type.

An initial thought would be to repurpose the "DONE" key that is placed between the page back "<<" and page forward ">>" buttons to provide a menu of available types. With 128 possible selections, a menu of nine (0) location types could bring the number of items per category down to fourteen (14) entries per type, although the distribution is likely to be more lumpy.