Ticket #3926 enhancement new
twisted.positioning -- a better positioning framework
|Reported by:||lvh||Owned by:||lvh|
|Component:||core||Keywords:||protocols gps positioning|
(diff, github, buildbot, log)
Description (last modified by lvh) (diff)
As some of you have undoubtedly noticed, Twisted's current GPS support (twisted.protocols.gps) has issues:
- The public API sucks:
- Fourteen arguments? All of them positional? Really?
- fooReceived methods are organized by what happens to be easy for NMEA sentences, not what makes sense
- It's hard to extend, raw objects are passed instead of pretty wrappers that abstract technology details away
- It's very protocol centric: the API changes between NMEA and Zodiac, a good API would look the same for any positioning technology
- There are no unit tests.
- It assumes we're using satellite navigation (well, not really, but only because there's no interface that says what it does)
This ticket is about a proposed alternative, twisted.positioning, which hopefully will:
- deprecate the existing code (#6810)
- support more than satellite-based navigation (such as cell triangulation) or maybe just more than GPS ( Galileo comes to mind)
After reviewing preliminary code and discussing the issue, we came to the following conclusions:
We need to have an interface (tentative name: IPositioningDataReceiver) that implements a number of methods, such as:
- positionRecieved(self, position)
- altitudeReceived(self, altitude)
- headingReceived(self, heading)
The parameters of these methods should not be simple objects (like floats or strs or bools), but Position, Heading... objects so that more API can be added later as required.
The classes that implement this should not continuously update their own state. Doing that is the job of the application that uses the framework.
Originally we thought it would be cool if accuracy data came together with positioning data, however this idea was dropped because it was unrealistic with real world positioning devices.
We should try to keep this API as general as possible (making as few assumptions about the underlying protocol as possible).
First thing to do should probably be finalizing the IPositioningReceiver interface. Getting it right is extremely important and has big implementation consequences: NMEA might present data in an illogical or useless order, but this shouldn't change our interface significantly.
This raises problems with the fooReceived methods, since data that is made available in chunks (headingRecieved doing both magnetic and true headings for example) might not have that data made available in the underlying implementation (some NMEA sentences only provide true heading, some proprietary ones only provide magnetic heading, and some sentences provide both -- it doesn't make sense to ignore the data from the first two types of sentence simply because they didn't have both kinds of heading).
The easy way out is to make the objects that the interface deals with as abstract as possible. With enough eyes, every problem is tiny, so your comments are much appreciated as usual.