access:trackwork_client_api
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
access:trackwork_client_api [2009/09/24 19:02] mmatthews |
access:trackwork_client_api [2012/10/10 17:11] (current) |
||
|---|---|---|---|
| Line 10: | Line 10: | ||
| * Project management | * Project management | ||
| * Server administration | * Server administration | ||
| + | * (MC) We might also use this for software licenses | ||
| - Support unauthenticated connections for GPS devices | - Support unauthenticated connections for GPS devices | ||
| * Only allow GPS/RTK position uploads. | * Only allow GPS/RTK position uploads. | ||
| - | * Will the TMM replacements require firmware downloands? | + | * Will the TMM replacements require firmware downloands? (No, I think this is more complicated than it's worth, MC) |
| - Control access to APIs dynamically. | - 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. | * Upon successful authentication the server should return enough information to allow the client to determine what that user has access to. | ||
| Line 23: | Line 24: | ||
| * 8 hours of data for a single GPS is roughly 30,000 points. | * 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. | * 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 only the data needed, not everything in the database. | ||
| * Transfer data in a reasonably compact format (probably not XML). | * Transfer data in a reasonably compact format (probably not XML). | ||
| Line 36: | Line 39: | ||
| ===== High Level Implementation Details ===== | ===== High Level Implementation Details ===== | ||
| + | ==== Functional Components ==== | ||
| + | |||
| + | I propose that we break the new Access Client into three areas of functionality: | ||
| + | - Library functions | ||
| + | - Server functions | ||
| + | - API functions | ||
| + | |||
| + | === Library Functions === | ||
| + | - Initialize the library and any underlying socket and 3rd party code. | ||
| + | - Shutdown the library and any underlying socket and 3rd party code. | ||
| + | - Provides a function to return server instances based on connection parameters (currently host name and port). | ||
| + | |||
| + | === General Server Functions === | ||
| + | - Connects to an instance of the server (based on host name and port). | ||
| + | - Authenticates client | ||
| + | - Manages allowed APIs based on the authentication state and the user configuration return from the server. | ||
| + | |||
| + | === API Functions === | ||
| + | API functions provide access to the actual data stored on the server. | ||
| + | - File API | ||
| + | * Functions for remote file storage (currently implemented as the AccessLib) | ||
| + | - Track API | ||
| + | * Functions for uploading/downloading GPS positions. | ||
| + | * Functions for managing tracks (move, delete, etc.) | ||
| + | * Functions for accessing GPS/Device statistics | ||
| + | - Project API | ||
| + | * Functions for managing projects (create, update, delete) | ||
| + | - Vehicle API | ||
| + | * Functions for managing vehicles (create, update, delete) | ||
| + | - Association API | ||
| + | * Functions for managing device/asset associations (create, update, delete) | ||
| + | - 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 Access Server | ||
| + | * Functions for monitoring/trouble shooting the Access Server | ||
| + | |||
| + | If we decide to allow customers to administrate their own users then I would break the Admin API up as follows: | ||
| + | - Admin API (customer access) | ||
| + | * Functions for managing users | ||
| + | - Support API (Agtek support access) | ||
| + | * Functions for managing customers | ||
| + | * Functions for adding/assigning devices to customers | ||
| + | * Functions for managing TMM configuration | ||
| + | * Functions for managing the Access Server | ||
| + | * Functions for monitoring/trouble shooting the Access Server | ||
| + | |||
| + | |||
| + | ==== API Access ==== | ||
| + | |||
| + | Access to the various API would be allowed as follows: | ||
| + | |||
| + | === Connected but not Authenticated === | ||
| + | This state occurs after a connection is made to the server but before authentication information has been sent. This is how devices will send data to the Access Server. The only API enabled will be the Track API, however all functions except upload will return an error. | ||
| + | |||
| + | === Connected and Authenticated === | ||
| + | This state occurs after a connection is made to the server and the user has been authenticated. Based on the user information returned by the server the library will enable APIs for subscribed services. | ||
| + | |||
| + | === Authenticated with Admin Privelages === | ||
| + | This state occurs when an authenticated user has admin privelages. If we decide to allow customers to administrate their own users then this may further break down into two levels: Customer based admin and Agtek support level admin. If we decide to do this then I think we have two levels of API, Admin API (customer admin) and Support API (Agtek support). | ||
access/trackwork_client_api.1253818963.txt.gz ยท Last modified: 2012/10/10 17:11 (external edit)
Page Tools
