[Twisted-Python] twisted.positioning: status report and request for comments/feedback

[Laurens Van Houtven]

Hi, and welcome to the discussion :-)

On Thu, Jul 30, 2009 at 6:18 PM, Santiago
Aguiar<santiago.aguiar at gmail.com> wrote:
> NMEAAdapter should delegate to a IPositionReceiver (which should be a
> Receiver, right? It's called Provider, maybe I'm missing something?),

Yes, it's been called IPositioningReceiver and IPositioningProvider at
different point in the past, I'm not sure which name is better.

> and avoid having to make the receiver inherit from the NMEAAdapter
> (which seems to be the case now, by looking at
> NMEAAdapter._sentence_received getattr(self, callbackName)). There will
> probably be tons of different GPS protocols (I sometimes work on
> tracking systems, and truth is many trackers don't send NMEA data but a
> proprietary protocol), and you don't want to have to subclass each to
> handle data from multiple sources.

Yes, I've been working with a number of GPS protocols as well from a
different project, I'm just porting it to Twisted (and making it much
better). However, in most commercial applications the only dominant
(and by dominant I mean "used by more than 1 manufacturer") protocol
seems to be SIRF. That's being implemented at some point in time too.

The suggested timeline right now is:

finalize NMEA implementation -> review -> work on GPSD (I've talked to
esr -- working on this sooner is mostly useless, the new gpsd protocol
is much preferred)

The downside of the new protocol in gpsd is that it introduces a new
dependency (gpsd). The upside is that it's json, so parsing it will be
easy, and we'll get something similar to NMEA, except immediately in a
good format.


> I also would refrain from using getattr tricks on the NMEA sentence
> classes. For me, the first line of python doc (specially on twisted!) is
> doing dir(obj) (and some IDEs/docgen tools actually do something like
> this for completion). getattr tricks and similar constructions makes it
> impossible to do this. It could be OK if you use getattr to handle an
> unknown case (for example, if you want to delegate based on whether the
> class has a method or not, even if in twisted interfaces world this
> wouldn't be the way to do, it I think), but in this case you know
> exactly what fields will the NMEA sentences have (and they won't change
> much!), so you could code them, even if this require much more code.
> It's the old motto of "write once maintain always" ;).

Yes, the point of dir working is a strong one -- I'm convinced that
this is a good idea too.

How about a bunch of properties, and have docstrings instead of @ivar
clauses in the class docstring? That way it'd be API compatible with
what I have now. It looks okay (from an API point). I'm more worried
about it being lots of duplicate and similar looking code. Well -- not
worried -- that's what put me off from doing it :-)

> You could also do other tricks, like update the class __dict__, so it
> would show as a regular field when the object is created, or dinamically
> create the class (like is done for TCPServer and friends, ugh), but
> really, it could be better to just write it.

Yeah,  abusing __dict__ sounds like a cure worse than the disease.

> Thanks for the code!! :)

Thanks for your comments :-)

So anyway, short summary on what I'm still going to do:

   - change the fixer methods so they produce abstract objects instead
of just nicer representations of NMEA string values in primitives
(from "1234.567", "N" -> 12 + 34.567/60 is already being done -- now,
it will produce a Coordinate object, too)
   - document all of NMEA's silly sentences in the NMEASentence object
   - change the fixer method to not rely on NMEASentence's internal dictionary

It might be a good idea to do the mapping from "good primitives" data
(eg, a float in decimal degrees with meaningful sign for a latitude)
to the abstract objects (Coordinate objects for example) separately.
This would mean an extra pass, but perhaps code could be shared
between the nmea and gpsd implementations then :-)

Laurens