Hi, and welcome to the discussion :-) On Thu, Jul 30, 2009 at 6:18 PM, Santiago Aguiar<santiago.agu...@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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
