• Store GPS points
• Send and Retrieve GPS Points (Autonomous or 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 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)

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

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)

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