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

Laurens Van Houtven lvh at laurensvh.be
Thu Jul 30 08:26:09 EDT 2009

On Thu, Jul 30, 2009 at 3:01 AM, Glyph Lefkowitz<glyph at twistedmatrix.com> wrote:
> Presumably the future plan is to have IPositioningProvider that receives
> data from something other than NMEA, as well?  (Other GPS protocols,
> whatever cell phones give you for triangulation, skyhook, etc.)

Yep, that's the idea.

> A minor nit here, would you put the interfaces in their own module,
> 'twisted.position.ipositioning'?

Done in new revision.

> There are multiple layers here.  Let's have an object for each layer.  The
> NMEA protocol parser object should send NMEA-sentence events to a sentence
> receiver object, then there should be an implementation of the
> sentence-receiver interface which generates positioning events and sends
> them on to a positioning-receiver interface.

Agreed. That's what I'm doing now -- see nmea.NMEASentence. This will
perpetuate through the rest of the code.

> I've attached a sketch, but it elides certain details like set-up and
> tear-down; there should be methods which allow users to tell when sentences
> and positions start and stop arriving.  The gist would be to have a
> connectionMade and connectionLost invoke startReceivingNMEA,
> stopReceivingNMEA, which in turn would invoke startReceivingPositions, and
> stopReceivingPositions.

Extremely helpful, thank you. I think I was confused because
LineReceivers, which make sense for NMEA since it's a line based text
protocol delimited by '\r\n', is-a protocol but is called "receiver",
so I figured my receiver should be a LineReceiver, and not that it
should be delegated from by a LineReceiver subclass. To be honest, it
still looks kind of wonky that a LineReceiver (well, a subclass)
delegates to a receiver, but maybe that's just my inexperience showing

What exactly would those
do? I don't think there's any setup to be done, so I guess that I
should just have an instance attribute on the appropriate class that
is set by startFoo/stopFoo. If it's false, callbacks don't fire.

> 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.

Okay, I'll do that as soon as people have reviewed the changes
suggested in your last mail, so that I know I got it right :-)

(also, sorry for the late reply -- the mailing list decided to make me
wait three hours before I could see my own mail, let alone yours)

Thanks for your input

More information about the Twisted-Python mailing list