On Thu, Aug 13, 2009 at 7:01 PM, Laurens Van Houtven <l...@laurensvh.be>wrote:
> 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?
>
> >
> > 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.
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
> 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?
>
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
> 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.
>
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.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
