access:trackwork_v.2_feature_requirements
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
access:trackwork_v.2_feature_requirements [2009/06/24 01:07] mikeclapp |
access:trackwork_v.2_feature_requirements [2012/10/10 17:12] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | [[main|Main Page]] | ||
| - | |||
| ====== Required Features ====== | ====== Required Features ====== | ||
| * Store GPS points | * Store GPS points | ||
| - | * Send and Retrieve GPS Points | + | * Send and Retrieve GPS Points (Autonomous or RTK) |
| * Create representative summary view for app (tracks, both TMM like device and RTK) | * Create representative summary view for app (tracks, both TMM like device and RTK) | ||
| - | * Administration utilities (backup, migration, archive, restore, add customer, delete customer, shipping delivery mechanism (ie: generating xml authentication if necessary) | + | * Administration utilities (backup, migration, archive, restore, add customer, delete customer, shipping delivery mechanism (ie: generating xml authentication file if necessary) |
| * Authentication for routing ID | * Authentication for routing ID | ||
| - | * Single (or few) ports open for entry | ||
| * Support for existing TMM's | * Support for existing TMM's | ||
| - | * bounded logs/ intelligent segregation | ||
| * Version aware C/C++ Client API for Windows/Windows Mobile applications | * Version aware C/C++ Client API for Windows/Windows Mobile applications | ||
| * friendly name association. Manual or RFID (assuming hardware becomes available) | * friendly name association. Manual or RFID (assuming hardware becomes available) | ||
| Line 21: | Line 17: | ||
| 6 devices running create: | 6 devices running create: | ||
| - | * 172,800 pts per day (8 hours) | + | * 172,800 pts per day (8 hours) ~ 7.25 mb (44 bytes per point) |
| - | * 864,000 pts per week (5 day) | + | * 864,000 pts per week (5 day) ~ 36.25 mb |
| - | * 3,456,000 pts per 4 week month | + | * 3,456,000 pts per 4 week month ~ 145 mb |
| - | * 44,928,000 pts per year | + | * 22,464,000 pts 6 months ~ 942.5 mb |
| + | * 44,928,000 pts per year ~ 1,885 mb | ||
| Line 48: | Line 45: | ||
| * Affects all of the server design considerably. We can't tack this on after the fact. | * Affects all of the server design considerably. We can't tack this on after the fact. | ||
| * Higher complexity for us and possibly the customer. | * Higher complexity for us and possibly the customer. | ||
| + | |||
| + | * Simple Web Interface | ||
| + | |||
| + | * Access Point Tracking Server (don't know if this is appropriate or not) | ||
| + | |||
| | | ||
| + | |||
| + | ==== Current implementation issues the new server should solve ==== | ||
| + | |||
| + | |||
| + | * Speed in App interaction. We send significantly more data than needed right now which impacts how fast an app displays, | ||
| + | * GPS points in files not an SQL Table. Teichert created 6 mil plus points for one job. After very many jobs, server performance is affected. Segregated by device and day. | ||
| + | * Intelligent, bounded logs. The Vasco logs were 6mb and growing. It makes it hard to see what's going on which is the whole point of logs. | ||
| + | * Opening lots of ports is a bottleneck, a potential security issue, and a point of resistance if we ever implement this outside of AGTEK. | ||
| + | * The client API is inefficient (many calls instead of few),bulky (no concept of just the data you need), and has no versioning (Trackwork has to change with every server change, no backward compatibility) | ||
access/trackwork_v.2_feature_requirements.1245805626.txt.gz · Last modified: 2012/10/10 17:12 (external edit)
Page Tools
