Embedded Traccar server? (Tracker device itself contains some of Traccar Server)
What is the benefit of doing this? What problem are you trying to solve?
Although the tracker device could directy interface with the MySQL database itself, there could be a very simple and dumb router bridge in between, this would take the stress of the MySQL DB for large numbers of concurrent connections.
What is the benefit of doing this? What problem are you trying to solve?
No actual problem, the reverse. This is something that would had been previously impossible, but now thanks to developments in hardware it is possible.
Standardisation I guess is an advantage
Advantage: much of the processing work can be off-loaded to the tracker hardware, leaving the map server more processor resource
Another advantage: Supports Traccar Server running on shared hosting or on a device on the Mobile Internet or IOT
Allowing direct public access to your database is a bad security practice in general.
Highly unlikely to happen. Tracker hardware is very diverse, some is relatively high powered, but a majority is not. This would just become another protocol to be supported.
Plus, once the data is in the SQL database, it would have to be read and processed, which I would guess is where the bulk of the processing power is required. The only saving you would really have is protocol translation.
There have been efforts to have common protocols before: http://www.opendmtp.org is one example. Device manufacturers have been noticeably absent in the effort to support common / open source protocols.
So highly unlikely that what you are proposing will work, in part because most current devices do not have the capability, in part because device manufacturers have historically not supported open standards, and in part because the actual infrastructure (network high latency / low bandwidth) will not support it.
Then even if supported, Traccar (and other tracking systems) will have to have some major changes to switch to supporting database reads.
Lastly, this will require all servers to have MySQL (for example) to be installed. Many of us do not want MySQL on our servers, as we have standardised on other solutions.
If I were developing a tracking system for my own purposes instead of relying on Traccar to do communicate with the devices and do the heavy lifting (a huge task to develop), I would probably have a tracker communication service that interacts with the trackers, and then loads the JSONified data to Redis queue(s). This could be placed on it's own server in the DMZ, and then Traccar (or other) could read the Redis queues.
But for myself, Traccar does an excellent job as-is, given the constraints it has to live within.
This is not another protocol, it's the opposite. This is eliminating protocols. And it's not anything to do with any existing GPS tracker. It's possibly also a chance for Traccar server IP to become licensable code in wide range of new embedded applications, not neccesarily as a GPS tracker.
a tracker communication service that interacts with the trackers, and then loads the JSONified data to Redis queue(s). This could be placed on it's own server in the DMZ, and then Traccar (or other) could read the Redis queues.
This is fine but to me it seems the communication service you have outlined still needs to deal with the very diverse different tracker protocols, essentially replicating the most challenging parts of the standard Traccar server (and other platforms) again. As you say, Traccar already does an excellent job given its operating constraints.
What I have in mind is the opposite. Tracker hardware and protocols have become extremely diverse. A GPS tracker device and its tracking platform were often designed as a pair, each by a different company taking their own approach. Then each buyer of new tracker model has to go through the routine of identifying the protocol multiplied by millions of people duplicating the same effort. Forums are filled with connection and protocol problems with new tracker.
Instead of a remote Traccar server listening and dealing with different protocols and molding the data into a standard format, that legwork instead is integrated within the tracker hardware itself as an embedded app. There have been some big leaps forward with latest generation of sistem-on-chip (SOC) programable hardware the capabilities now are mindblowing at very low power consumpt9ion and becoming cheap as chips. All the protocol stuff instead happens inside the tracker itself, which sends out a standardised generic message format straight to a database (via SSL layer and any extra needed security enhancements) with no translation other than the security layer. Instead of having over the Internet all the protocol headaches, all that instead happens across a silicon chip already done and solved in the design lab once and for all, not dumped out to the Internet to solve.
As I say, this is not a protocol, it's the opposite. The whole thing could be almost like a standard 'media format'.
Nothing changes with the Traccar Server. No extra protocol to add. If anything the Traccar server gets simpler not more complex.
Lastly, this will require all servers to have MySQL (for example) to be installed. Many of us do not want MySQL
It can be any database that Traccar supports, doesn't need to be MySQL. As I said, there are no changes to Traccar server, and if they were it would be to enhance security.
Something I've noticed about these ideas like this, they appear every now and again they get hammered on Internet forums as 'un-workable' and then ... Lo and behold ... a year or three later it's then someone's product or it gets included into a Google or Facebook product.
If it's not a new "protocol", what is it? To me it sounds like yet another way to report data to the server.
This is the complete opposite of a new protocol and no significant changes with the way to report data to the server. It's just the boundary has moved.
If anything it's a driving force to reduce protocols . You're replacing an infinite number of monkeys with typewriters with a hardware development lab
Could the part of the Traccar server functionality be embedded into the physical tracker device's firmware?
The tracker device writes data directly to a remote MySQL database hosted on a server with public IP address. On the server a regular (or custom build) Traccar server reads out the MySQL database and hosts the HTTP on 8082 in the usual way.
All tracker devices doing this would be forced to submit standard format data instead of different standards. The MySQL database data layout is a cohesive force to standardise.
Anyone else had this idea? ESP32 and ARM etc. etc. microcontrollers hardwares have lots of resource.