Update the post-3.12 to-do list.

1 files changed, 62 insertions, 52 deletions

diff --git a/TODO b/TODO
index c3e647bd..93db70da 100644
--- a/TODO
+++ b/TODO
@@ -8,6 +8,16 @@ the "Hacking Guide" on the project website.
 The list of bugs exposed by gpsd in other software has moved to
 the "Upstream Bugs" page on the project website.
 
+** Documentation **
+
+We now have two different calibration procedures in the Tine Service
+HOWTO. One was written by Gary and is based on peerstats; the other by
+Sanjeev Gupta and is based on loopstats.
+
+Can these be merged? How do we know which is appropriate to use when?
+What could we build in the way of tools and visualization aids to make
+the calibration process less annoying?
+
 ** Bugs in gpsd and its clients:
 
 *** Tracker bugs
@@ -16,6 +26,58 @@ See the GPSD bug tracker on the project website, but don't be
 surprised if it's empty or very sparse.  Our rate of new defects per
 month is quite low.
 
+*** RFC2783 bugs
+
+**** detangle TIOCMIWAIT and RFC2783
+
+Currently, the code for RFC2783 seems to depend (logically) on
+TIOCMIWAIT support.  However, RFC2783 (and really, no standard)
+defines TIOCMIWAIT, and NetBSD (and probably FreeBSD) do not implement
+it.  So, there really should be two separate implementations, one that
+works with TIOCMIWAIT (and thus only on Linux and OpenBSD) and one
+that assumes only RFC2783 (and thus works on Linux, FreeBSD and
+NetBSD, as well as any future system that complies with RFC2783 and
+uses the serial port for time_pps_init).
+
+*** Client bugs
+
+**** In gpsmon's PPS Offset field
+
+Presently PPS Offset is displayed in direct mode for NMEA, SiRF, and
+UBX devices.  Others should probably do likewise, notably the
+Motorola Oncore and Garmin drivers.
+
+*** Dispatcher/network issues
+
+**** Reading AISHub data via UDP confuses xgps with short writes
+
+To reproduce, "gpsd -D 5 -N -n udp://192.168.1.3:12346" (only
+works inside thyrsus.com) and run xgps. Probably some kind of
+packet aggregation issue as it doesn't happen with test logs.
+
+*** Driver issues
+
+**** RTCM3 analysis is incomplete
+
+We can presently decode RTCM3 messages of type 1001-1014, 1029, and
+1033.  This is not the complete set. We need more test data with
+different types in them, and a copy of the RTCM3 standard at latest
+revision (all we have is revision 3).
+
+The support for unpacking RTCM3 sentences in the client library is
+limited to 1001, 1002, 1007, 1008, 1009, 1010, 1014, and 1033. There
+are some design issues with the baby JSON parser that are going to 
+make extending this set difficult.
+
+**** Reporting code for specialized Type 6 and 8 AIS messages is incomplete.
+
+This one is mine and Kurt Schwehr's. Support is currently nearly
+complete; the only missing cases are a handful of IMO 236 and IMO 289
+message 6 and 8 subtypes - specifically, 6/23, 8/21, 8/22, 8/24, and
+8/26.
+
+** New features **
+
 *** Time tracking
 
 Our goal is to be independent of the system clock.
@@ -69,27 +131,6 @@ However, Iván Sánchez Ortega notes:
 >I, for one, would like to see the secs/msecs problem solved before GPSD
 >embarks on the enterprise of writing TAGblocks.
 
-*** RFC2783 bugs
-
-**** detangle TIOCMIWAIT and RFC2783
-
-Currently, the code for RFC2783 seems to depend (logically) on
-TIOCMIWAIT support.  However, RFC2783 (and really, no standard)
-defines TIOCMIWAIT, and NetBSD (and probably FreeBSD) do not implement
-it.  So, there really should be two separate implementations, one that
-works with TIOCMIWAIT (and thus only on Linux and OpenBSD) and one
-that assumes only RFC2783 (and thus works on Linux, FreeBSD and
-NetBSD, as well as any future system that complies with RFC2783 and
-uses the serial port for time_pps_init).
-
-*** Client bugs
-
-**** In gpsmon's PPS Offset field
-
-Presently PPS Offset is displayed in direct mode for NMEA, SiRF, and
-UBX devices.  Others should probably do likewise, notably the
-Motorola Oncore and Garmin drivers.
-
 *** Time offset debugging in gpsmon ***
 
 Hall Murray:
@@ -142,37 +183,6 @@ Anthony Stirk <upuaut@gmail.com> writes on Wed May 21 06:09:00 2014:
 A possibility: drop the chip to low-power mode when it can see > 4
 sats, revert to normal otherwise.
 
-*** Dispatcher/network issues
-
-**** Reading AISHub data via UDP confuses xgps with short writes
-
-To reproduce, "gpsd -D 5 -N -n udp://192.168.1.3:12346" (only
-works inside thyrsus.com) and run xgps. Probably some kind of
-packet aggregation issue as it doesn't happen with test logs.
-
-*** Driver issues
-
-**** RTCM3 analysis is incomplete
-
-We can presently decode RTCM3 messages of type 1001-1014, 1029, and
-1033.  This is not the complete set. We need more test data with
-different types in them, and a copy of the RTCM3 standard at latest
-revision (all we have is revision 3).
-
-The support for unpacking RTCM3 sentences in the client library is
-limited to 1001, 1002, 1007, 1008, 1009, 1010, 1014, and 1033. There
-are some design issues with the baby JSON parser that are going to 
-make extending this set difficult.
-
-**** Reporting code for specialized Type 6 and 8 AIS messages is incomplete.
-
-This one is mine and Kurt Schwehr's. Support is currently nearly
-complete; the only missing cases are a handful of IMO 236 and IMO 289
-message 6 and 8 subtypes - specifically, 6/23, 8/21, 8/22, 8/24, and
-8/26.
-
-** To do:
-
 ***  Make subframe reports available in the C API.
 
 gpsd now reports subframes when they're available, but the C client