One of the most useful facilities provided by the SensorShell is offline data storage. Example 16.2, “Offline data storage” illustrates the creation of offline storage through an invocation of the SensorShell interactively.

C:\>java -jar sensorshell.jar
Hackystat Version: 7.3.221 (February 21 2006 09:54:20)
SensorShell started at: 02/21/2006 14:19:09
Type 'help' for a list of commands.
Host: http://hackystat.ics.hawaii.edu:999/ is not available or key not valid.
Defined shell command: DevEvent
Defined shell command: UnitTest
Defined shell command: BuffTrans
Defined shell command: Commit
Defined shell command: Build
AutoSend enabled every 10 minutes.
Server not available; offline data not recovered this session.
>> DevEvent#add#type=edit#path=c:\foo\bar\Baz.java
DevEvent add OK (1 total)
>> quit
Server not available. Storing commands offline.
Sensor data stored in: C:\Documents and Settings\johnson\.hackystat\offline\2006.02.21.14.19.41.578.ser

Before bringing up the SensorShell, I changed my hackystat host to "http://hackystat.ics.hawaii.edu:999/", which is not an available server. The fourth line of the output indicates that the Ping failed, and that either the host or key value was not correct. At the end of the initialization section, the SensorShell indicates that since it cannot contact the server, it will not attempt to restore any offline data that might be currently stored locally on the client.

The next part of this example adds some DevEvent sensor data to the SensorShell. This command succeeds normally, since the data is buffered and there is no attempt to contact the server.

After adding the sensor data, I invoked the "quit" command. As explained in the previous section, the quit command implicitly invokes the "send" command. This is where things get interesting. Since the server is not known, the SensorShell takes all of the buffered data (in this case, just the single DevEvent), and stores it in a single serialized Java file in the .hackystat/offline directory. The name of the file is constructed to indicate the date and time at which it was created. In the above example, it was created on February 21, 2006, at 19 minutes, 41 seconds, and 578 milliseconds past 2 o'clock in the afternoon. Besides providing documentation about the serialized file, this file naming scheme makes it extremely unlikely that a user running multiple tools with sensors offline will create files whose names conflict with each other.

Now suppose that sometime later the Hackystat host comes back online. (For this example, I will simulate that by correcting the URL to the public hackystat server in my sensor.properties file.) Example 16.3, “Offline data retrieval” illustrates what happens when we invoke the SensorShell at this point:

C:\Documents and Settings\johnson\Desktop>java -jar sensorshell.jar
Hackystat Version: 7.3.221 (February 21 2006 14:28:44)
SensorShell started at: 02/21/2006 14:44:35
Type 'help' for a list of commands.
Host: http://hackystat.ics.hawaii.edu/ is available and key is valid.
Defined shell command: DevEvent
Defined shell command: UnitTest
Defined shell command: BuffTrans
Defined shell command: Commit
Defined shell command: Build
AutoSend enabled every 10 minutes.
Checking for offline data to recover.
Recovering offline data from: 2006.02.21.14.32.02.484.ser
DevEvent add OK (1 total)
Sending sensor data (02/21 14:44:36)
  Ping: Ping OK (contacted server http://hackystat.ics.hawaii.edu/ with valid key.)
  AutoSend: AutoSend OK ('send' command ignored)
  DevEvent: Send OK (1 entries)
  Commit: Send OK (No entries to send.)
  BuffTrans: Send OK (No entries to send.)
  UnitTest: Send OK (No entries to send.)
  Build: Send OK (No entries to send.)
>> Summary of recovered offline data:
02/21/2006 14:31:59#DevEvent#add#type=edit#tool=Sensor Shell#tstamp=1140568319390#path=c:\foo\bar\Baz.java
>>

This example starts out like a normal session: the hackystat host is contacted successfully, the ShellCommands are defined, and so forth. Then, when it checks for offline data to recover, it discovers a file in the .hackystat/offline directory. It then reads this file in, reconstructs the DevEvent "add" command from the prior session, re-invokes that "add" command (resulting in the "DevEvent add OK (1 total)" output line), immediately sends all of the data from the serialized file to the server, and finally outputs a summary of the data it discovered for reference purposes. At that point the session can continue normally.