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 file if necessary)
Authentication for routing ID
Support for existing TMM's
Version aware C/C++ Client API for Windows/Windows Mobile applications
friendly name association. Manual or RFID (assuming hardware becomes available)
Useful Errata
6 devices running create:
172,800 pts per day (8 hours) ~ 7.25 mb (44 bytes per point)
864,000 pts per week (5 day) ~ 36.25 mb
3,456,000 pts per 4 week month ~ 145 mb
22,464,000 pts 6 months ~ 942.5 mb
44,928,000 pts per year ~ 1,885 mb
Possible Future Features
These are things I can see us doing but could also be a major undertaking: They're included as talking points and may either disappear through consensus or move up to the feature requirements. Feel free to tack on stuff.
File Storage Capability (subset of Box.net capabilities)
Benefits
single login, shared data
simplified user experience, create web page interface
total control
Drawbacks
Time, big project
added complexity
probably more expensive
Project Permissions/ Access Control
Benefits
Potential customer hygiene solution.
Sales Demo examples can be shared without fear of inadvertent deletion.
Drawbacks
Affects all of the server design considerably. We can't tack this on after the fact.
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)