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
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)
   • 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.