[Twisted-Python] twisted.positioning: progress report + Factory question

Laurens Van Houtven lvh at laurensvh.be
Thu Aug 13 19:01:12 EDT 2009

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:
>> Short question up front: what exactly should be in the proposed
>> factory class? What does it take? What does it return?
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8)


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

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

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

More information about the Twisted-Python mailing list