-----=: app/views/About.html
   JSON Location Tracker

  About

   Written by [1]Paul Miller in frustration of the absence of Google Latitude
   for the prē. At the time of this writing, there did exist other homebrew
   projects with similar functionality, but none on Github — or with the
   precise feature-set desired. It was later discovered that Latitude is
   already (kindof) on the phone. But you can do a lot more with the Google
   Maps API than you can with [2]Latitude anyway.

   Bugs and problems should be reported in the Github issue tracking system.
   If that is not possible or not desireable, use the [3]feedback email
   address instead.
   [4]http://github.com/jettero/jlt/issues

   The entire source for this app and sample websites in various languages
   can be found here:
   [5]http://github.com/jettero/jlt

   Further release candidates and unreleased versions are usually available
   here first:
   [6]http://jettero.github.com/jlt

  Copyright

   This app and most of the CGI code is Copyright Paul Miller 2011.

  License

   This source for this app and all the CGI source is licensed under the GNU
   GPLv3.

  Thanks

   There were additional contributions made by the following people:

     * [7]Matt Colyer
     * [8]DJCP
     * [9]NateVW

  Latitude?

   This app is not intended to complete with or connect to Google Latitude,
   which has a similar mission. It may interest you to know that Google
   already pushes Latitude functionality to the Prē, but it's hidden. Turn it
   on by tapping here:
   [10]http://maps.google.com/maps/m?mode=latitude

References

   Visible links
   1. https://voltar.org/
   2. file:///home/jettero/code/webos/jlt/app/views/About.html#latitude
   3. mailto:jlt-feedback@voltar.org
   4. http://github.com/jettero/jlt/issues
   5. http://github.com/jettero/jlt
   6. http://jettero.github.com/jlt
   7. http://github.com/MattColyer
   8. http://github.com/djcp
   9. http://github.com/natevw
  10. http://maps.google.com/maps/m?mode=latitude

-----=: app/views/Help.html
   JSON Location Tracker

  Indicator Meanings

   There are various text phrases that appear below the indicators at the
   time. Along the left, they describe the number of readings taken and how
   many were accepted by the webserver (e.g., 2 reads, 2 posted). Along the
   right, the app shows when an HTTP (aka AJAX) request is running (e.g. HTTP
   running)^1.

   In addition to the text messages, there is a slider and there are three
   LEDs. The slider indicates the buffer fill status. If the slider is full
   (filling left to right), it indicates the buffer is full. Consider
   increasing the buffer size if this happens frequently.

   The blue LED indicates some type of GPS activity. Usually the blue LED
   indicates a new read being buffered, but it can also indicate buffer
   overruns. When a buffer overrun occurs, the blue LED will light with the
   red LED simultaneously.

   The green LED indicates some type of HTTP activity. Usually this activity
   relates to a successful data POST. However, when a POST fails, the green
   LED will light along with the red LED.

  Post URL

   To edit this field, tap-and-hold for a second or two. The field resists
   accidental edits. It is the URL at your website you wish to post the GPS
   data to. There are [1]samples in several languages on github (see the
   About card).

   The Post URL is is the full path of the CGI that should collect your JSON
   location posts. The format of the posts is listed in a file called
   "[2]PROTOCOL" in the distribution (ibid).

  View URL

   The view url isn't used internally. It is only used when sending your
   location to friends, where it is effectively pasted into the message.

  Update Intervals

   There are two ways to acquire GPS data from the webOS. First, you can ask
   for a fix, and second, you can subscribe to the GPS system and it will
   give updates as often as it likes. In practice, this tends to be roughly
   every second. When switched to "Continuous Updates", your device will
   subscribe to the updates and store them as often as they come.

   Alternatively, you can set the app to ask for a fix only after waiting for
   a certain amount of time (called the Update Interval) after receiving the
   last fix.

  Buffer Size

   While waiting for upload confirmation, this app stores the GPS fixes
   locally. In slow network locations, a larger buffer may help ensure
   successful uploads — however, it will also consume more local resources.

   If the current GPS fix is "very close" to the last location, the app will
   store additional timestamps rather than duplicating the gps fix. The
   buffer setting affects this timestamp queue also. The app will store up to
   three times the buffer size worth of timestamps in a single message before
   overflowing. That is, if the buffer size is five messages, the app will
   store at most fifteen timestamps per location entry and only five
   locations; giving at most: seventy-five readings, if everything happens to
   line up just right.

   When the message buffer is full and a reading comes in, an older messages
   will be shifted off in FIFO order. When the timestamp buffer of a fix
   object is full, it will push another message into the queue instead.

  Tags and POI

   In the lower left of the control panel is a submenu for tags and POI.

   If you have noticed a Point of Interest (POI), click POI to send a note to
   the webserver. This message will be transmitted exactly once and the
   interface will attempt to get a fix as soon as possible — despite any
   slower update intervals, as above described.

   Trip tags, on the other hand, are sent with each fix. They're intended to
   give text labels to each fix (e.g., "drive to work", "drive to cottage").

  Send View

   As a convenience, the JLT may be instructed to prefill an IM/SMS or Email
   with the viewing location of your gps data. The contents of the message
   will be little more than the view url (if set) above described.

  Authentication

   Authentication (if required) depends on the endpoint and related
   negotiation. If requested, the JLT will pop open a browser for
   authentication purpopses. WebOS keeps browsers and apps completely
   separate though, so the only way to get the authentication token from the
   website to the application is to cut and paste it over.

   For this reason, the browser has an (i) button you can press that will pop
   up a token request window. Simply copy your auth token — typically the id
   of a session on the webserver — to the dialog and press the set button.

  Side Notes

   ^1 The number of posted messages will sometimes lag behind the number of
   actual reads because of two factors: 1) webserver acknowledgments do not
   contain a count and 2) occasionally a reading will be lost when a fix
   message is acknowledged but has gained timestamps after the message was
   sent to the webserver. This behavior is not considered to be a bug at this
   time.

References

   Visible links
   1. http://github.com/jettero/jlt/tree/master/cgi/
   2. https://github.com/jettero/jlt/raw/master/PROTOCOL