Currently the trackwork server and the file storage server are accessed through separate APIs. The new Access Server will combine both pieces of functionality into one client side API.

1. Single authentication for all APIs including:
   • File storage
   • Track storage
   • Project management
   • Server administration
   • (MC) We might also use this for software licenses
2. Support unauthenticated connections for GPS devices
   • Only allow GPS/RTK position uploads.
   • Will the TMM replacements require firmware downloands? (No, I think this is more complicated than it's worth, MC)
3. Control access to APIs dynamically.
   • Upon successful authentication the server should return enough information to allow the client to determine what that user has access to.
   • For example, a customer may have paid for track storage but not file storage.
4. Forward/Backward compatibility between the client and the server
   • The client and server should be able to communicate across a reasonable range of software versions without having to load multiple versions of the client library.
5. The API should be abstract enough that changes to the underlying implementation do not have a major impact on the client application.
   • Specifically, we will probably change how the file storage is implemented. This should require little or no change to the client application.
6. Optimized data transfer
   • 8 hours of data for a single GPS is roughly 30,000 points.
   • Customers will probably want to download an entire day's worth of data at once.
     • (MC) This may be implied, but we also want to be able to download small chunks at a time (updating tracks)
     • (MM) If we optimize for large data transfer, small should be perform fast as well.
   • Transfer only the data needed, not everything in the database.
   • Transfer data in a reasonably compact format (probably not XML).
7. Optimized download API
   • Need to coordinate with the client team to make sure the API for downloading points is implemented in a fashion that optimizes both memory usage and speed when downloading GPS points.
   • Pre-allocated arrays? Callbacks? Partial downloads?
   • May need to implement multiple solutions.
8. Windows Mobile Support
   • Make sure the library is compatible with both UNICODE and multi-byte character sets.
   • Separate out the pieces that may not be portable to Mobile so that they can be compiled out.
     • For example, file storage currently requires the libcurl library which may not be easily portable to Mobile.

I propose that we break the new Access Client into three areas of functionality:

1. Library functions
2. Server functions
3. API functions

1. Initialize the library and any underlying socket and 3rd party code.
2. Shutdown the library and any underlying socket and 3rd party code.
3. Provides a function to return server instances based on connection parameters (currently host name and port).

1. Connects to an instance of the server (based on host name and port).
2. Authenticates client
3. Manages allowed APIs based on the authentication state and the user configuration return from the server.

API functions provide access to the actual data stored on the server.

1. File API
   • Functions for remote file storage (currently implemented as the AccessLib)
2. Track API
   • Functions for uploading/downloading GPS positions.
   • Functions for managing tracks (move, delete, etc.)
   • Functions for accessing GPS/Device statistics
3. Project API
   • Functions for managing projects (create, update, delete)
4. Vehicle API
   • Functions for managing vehicles (create, update, delete)
5. Association API
   • Functions for managing asset/vehicle associations (create, update, delete)
6. Admin API (may only be implemented in the Java library)
   • Functions for managing customers
   • Functions for managing users
   • Functions for adding/assigning devices to customers
   • Functions for managing TMM configuration
   • Functions for managing the AccessServer
   • Functions for monitoring/trouble shooting the AccessServer