[Twisted-Python] twisted.positioning: progress report + Factory question
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Short question up front: what exactly should be in the proposed factory class? What does it take? What does it return? Second question: what should NMEASentence attributes look like? Properties? There are some proposed things in t.p.nmea in trunk. Also, progress report: - NMEAAdapters now correctly fire callbacks on receivers. There are tests that show this working for multiple sentences. - NMEA date support. You now get callbacks with date and time. New things can be found in trunk at the usual places (launchpad). Work in progress: - satellite information support (this is hairy because unlike other sentences, the *same* fields are across multiple sentences :/) - error support (this is hairy because the subset of NMEA that everyone supports essentially has no useful information about this) Basically error support is a lot of work but boring, satellite support is not so much work but hairy and disgusting NMEA internals handling. I'm working on error support first because it's still early in the morning. thanks for listening Laurens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8) iEYEARECAAYFAkqD6hgACgkQT5v5zGkvKT4EWgCeM9GVVKSqMOw/FqXVsqn0D+pT iDMAoMvCY5imsfDrH+6gKnj+ssGrAYlb =GnpZ -----END PGP SIGNATURE-----
On Thu, Aug 13, 2009 at 6:26 AM, Laurens Van Houtven <lvh@laurensvh.be>wrote:
Short question up front: what exactly should be in the proposed factory class? What does it take? What does it return?
Factory class proposed by whom and for what? If it's a thing that creates IPositionReceivers, it should return an IPositionReceiver and take some description of where the position data is coming from. The existing analogue is IProtocolFactory.buildProtocol, which is takes an IP address. I assume that the "address" object in GPS's case is something that identifies the capabilities of the position-information-providing widget and its type (GPS, skyhook, tower triangulation, etc). Second question: what should NMEASentence attributes look like?
Properties? There are some proposed things in t.p.nmea in trunk.
By "trunk" I hope you mean "not trunk, the branch". Maybe you meant HEAD? Also, progress report:
Great!
New things can be found in trunk at the usual places (launchpad).
... "in the branch" at the usual place ;-).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Heh, sorry, I'm so used to saying stuff's in trunk it's become second nature :-) On Thu, Aug 13, 2009 at 9:35 PM, Glyph Lefkowitz wrote:
iEYEARECAAYFAkqEmvwACgkQT5v5zGkvKT7QUACeNtOQcZigbzZNK8B+8pz9kjt0 Vf4AoMDt1+xS3aQjuFUeX09K5Fd3U1jL =5wtd -----END PGP SIGNATURE-----
Factory class proposed by whom and for what?
I think that was you, and I think it was for gluing the classes in NMEA together. From your mail on July 30:
There should also be a factory which nicely hooks everything together and takes only a factory for your IPositioningProvider, so that users can quickly get started with a positioning provider.
I'm not sure what a factory that takes a factory is. I'd think it's something that implements IPositioningProvider (eg a class) and then returns the instance?
Would this be the correct place to implement behavior like "listen on a bunch of serial ports, until you find something that spews things that look like NMEA at you", or should that be another level of abstraction up? Would there be multiple such factories for different kinds of positioning? I don't know what cell ID will need to know to set up an IPositioningProvider, but the NMEA factory and gpsd factory need completely different kinds of information, for example. Thanks for your reply Laurens
On Thu, Aug 13, 2009 at 7:01 PM, Laurens Van Houtven <lvh@laurensvh.be>wrote:
That was a typo. There should be a *method* which nicely hooks everything together and takes only a factory (etc).
I'd think it's something that implements IPositioningProvider (eg a class) and then returns the instance?
That's basically right, but I think you might want a separate object. There are other notifications you might want to send to a factory that you wouldn't want to send to an instance; for example, "no positioning information is available, I will never send you any position data". On the other hand, you could just have the class classProvides() the factory interface and implements() the main interface for convenience, since a class *is* really a factory in Python. There should actually be several methods which hook things together. One would simply be to construct an NMEAReceiver and give it an IPositionReceiver directly. Another would be to call a function that scans your serial ports, inspects your Windows registry (or whatever) and discovers all GPS devices, normalizes them into a single stream of positioning events, and calls IPositionReceiverFactory.createPositionReceiver() Would this be the correct place to implement behavior like "listen on
There should be both levels of abstraction. At one level you've got SerialPort(NMEAReceiver(MyPositionReceiverFactory().createPositionReceiver(PositionSource(positioning.NMEA, positioning.SerialPort("/dev/ttyS1")), "/dev/ttyS1") and at another you've got startGettingPositioningDataSomehow(MyPositionReceiverFactory()). The latter should be implemented in terms of the former. Would there be multiple such factories for different kinds of
Absolutely. The key idea here is that you want there to be a complete separation between application logic (which is your IPositioningReceiver or IPositioningReceiverFactory) and your byte-level parsing code (which is your NMEA or gpsd or Rockwell or cell triangulation or whatever). Then, at the top level This is exactly analogous to the way that you can have an IProtocolFactory, completely independent of any stream-communication API. Later, you can do listenSSL or listenTCP, or, with a very slight modification, connectSSL or connectTCP. listenSSL has a different signature from listenTCP, after all. You need to be able to give it a certificate. You could also have connecting via SSH connections, via subprocesses, etc; all of these have radically different requirements for construction and set-up, but once you're going they should all be able to talk to an IProtocol.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not really a direct reply, but the following is big enough progress that it warrants a minireport of its own. An excerpt from my test suite running: test_GSVSentences ... , , , }> , , , }> , , }> ... meaning GSV sentences are now correctly parsed! :-) According to esr (who knows what he's doing when it comes to NMEA parsers) this is by far the hardest part: parsing GSV properly should take about as long as everything else put together. It was a bit of a pain to glue it together with everything else, but according to a few smart people this probably means that the _rest_ of my parser is sane :-) (GPGSV splits the same kind of field across multiple sentences, and whether they override or not is dependent on other fields which may or may not be in the same sentence. No other sentence does this.) Also, there's support now for GPGLL (pure lat/lon) and GPHDT (true heading made good) sentences, but those were so simple compared to the disaster that is GPGSV it's not even funny. Next up: GSA sentence support. You can expect this behavior in the branch head on lp some time later today, when I'm done committing test sentences from known-pathologically-bad GPS devices, to see how badly the parser chokes on them. Bad news: I'm going to be extremely busy the next few days so very little time to actively commit code. Enjoy, Laurens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8) iEYEARECAAYFAkqG0SQACgkQT5v5zGkvKT5dOgCg1jWqrgvpOyIwHCrlcH48DE/C eqQAoI9XdaSfIzNgICoJbXur/0LzwbRv =4Uvy -----END PGP SIGNATURE-----
For some arcane reason, GMail (or maybe FireGPG) decided to mangle the stuff in between commas. *sigh* http://paste.pocoo.org/show/134450/ Laurens
On Thu, Aug 13, 2009 at 6:26 AM, Laurens Van Houtven <lvh@laurensvh.be>wrote:
Short question up front: what exactly should be in the proposed factory class? What does it take? What does it return?
Factory class proposed by whom and for what? If it's a thing that creates IPositionReceivers, it should return an IPositionReceiver and take some description of where the position data is coming from. The existing analogue is IProtocolFactory.buildProtocol, which is takes an IP address. I assume that the "address" object in GPS's case is something that identifies the capabilities of the position-information-providing widget and its type (GPS, skyhook, tower triangulation, etc). Second question: what should NMEASentence attributes look like?
Properties? There are some proposed things in t.p.nmea in trunk.
By "trunk" I hope you mean "not trunk, the branch". Maybe you meant HEAD? Also, progress report:
Great!
New things can be found in trunk at the usual places (launchpad).
... "in the branch" at the usual place ;-).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Heh, sorry, I'm so used to saying stuff's in trunk it's become second nature :-) On Thu, Aug 13, 2009 at 9:35 PM, Glyph Lefkowitz wrote:
iEYEARECAAYFAkqEmvwACgkQT5v5zGkvKT7QUACeNtOQcZigbzZNK8B+8pz9kjt0 Vf4AoMDt1+xS3aQjuFUeX09K5Fd3U1jL =5wtd -----END PGP SIGNATURE-----
Factory class proposed by whom and for what?
I think that was you, and I think it was for gluing the classes in NMEA together. From your mail on July 30:
There should also be a factory which nicely hooks everything together and takes only a factory for your IPositioningProvider, so that users can quickly get started with a positioning provider.
I'm not sure what a factory that takes a factory is. I'd think it's something that implements IPositioningProvider (eg a class) and then returns the instance?
Would this be the correct place to implement behavior like "listen on a bunch of serial ports, until you find something that spews things that look like NMEA at you", or should that be another level of abstraction up? Would there be multiple such factories for different kinds of positioning? I don't know what cell ID will need to know to set up an IPositioningProvider, but the NMEA factory and gpsd factory need completely different kinds of information, for example. Thanks for your reply Laurens
On Thu, Aug 13, 2009 at 7:01 PM, Laurens Van Houtven <lvh@laurensvh.be>wrote:
That was a typo. There should be a *method* which nicely hooks everything together and takes only a factory (etc).
I'd think it's something that implements IPositioningProvider (eg a class) and then returns the instance?
That's basically right, but I think you might want a separate object. There are other notifications you might want to send to a factory that you wouldn't want to send to an instance; for example, "no positioning information is available, I will never send you any position data". On the other hand, you could just have the class classProvides() the factory interface and implements() the main interface for convenience, since a class *is* really a factory in Python. There should actually be several methods which hook things together. One would simply be to construct an NMEAReceiver and give it an IPositionReceiver directly. Another would be to call a function that scans your serial ports, inspects your Windows registry (or whatever) and discovers all GPS devices, normalizes them into a single stream of positioning events, and calls IPositionReceiverFactory.createPositionReceiver() Would this be the correct place to implement behavior like "listen on
There should be both levels of abstraction. At one level you've got SerialPort(NMEAReceiver(MyPositionReceiverFactory().createPositionReceiver(PositionSource(positioning.NMEA, positioning.SerialPort("/dev/ttyS1")), "/dev/ttyS1") and at another you've got startGettingPositioningDataSomehow(MyPositionReceiverFactory()). The latter should be implemented in terms of the former. Would there be multiple such factories for different kinds of
Absolutely. The key idea here is that you want there to be a complete separation between application logic (which is your IPositioningReceiver or IPositioningReceiverFactory) and your byte-level parsing code (which is your NMEA or gpsd or Rockwell or cell triangulation or whatever). Then, at the top level This is exactly analogous to the way that you can have an IProtocolFactory, completely independent of any stream-communication API. Later, you can do listenSSL or listenTCP, or, with a very slight modification, connectSSL or connectTCP. listenSSL has a different signature from listenTCP, after all. You need to be able to give it a certificate. You could also have connecting via SSH connections, via subprocesses, etc; all of these have radically different requirements for construction and set-up, but once you're going they should all be able to talk to an IProtocol.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not really a direct reply, but the following is big enough progress that it warrants a minireport of its own. An excerpt from my test suite running: test_GSVSentences ... , , , }> , , , }> , , }> ... meaning GSV sentences are now correctly parsed! :-) According to esr (who knows what he's doing when it comes to NMEA parsers) this is by far the hardest part: parsing GSV properly should take about as long as everything else put together. It was a bit of a pain to glue it together with everything else, but according to a few smart people this probably means that the _rest_ of my parser is sane :-) (GPGSV splits the same kind of field across multiple sentences, and whether they override or not is dependent on other fields which may or may not be in the same sentence. No other sentence does this.) Also, there's support now for GPGLL (pure lat/lon) and GPHDT (true heading made good) sentences, but those were so simple compared to the disaster that is GPGSV it's not even funny. Next up: GSA sentence support. You can expect this behavior in the branch head on lp some time later today, when I'm done committing test sentences from known-pathologically-bad GPS devices, to see how badly the parser chokes on them. Bad news: I'm going to be extremely busy the next few days so very little time to actively commit code. Enjoy, Laurens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8) iEYEARECAAYFAkqG0SQACgkQT5v5zGkvKT5dOgCg1jWqrgvpOyIwHCrlcH48DE/C eqQAoI9XdaSfIzNgICoJbXur/0LzwbRv =4Uvy -----END PGP SIGNATURE-----
For some arcane reason, GMail (or maybe FireGPG) decided to mangle the stuff in between commas. *sigh* http://paste.pocoo.org/show/134450/ Laurens
participants (2)
-
Glyph Lefkowitz -
Laurens Van Houtven