<br><div class="gmail_quote">On Thu, Aug 13, 2009 at 7:01 PM, Laurens Van Houtven <span dir="ltr"><<a href="mailto:lvh@laurensvh.be" target="_blank">lvh@laurensvh.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
On Thu, Aug 13, 2009 at 9:35 PM, Glyph Lefkowitz wrote:<br>
>> Short question up front: what exactly should be in the proposed<br>
>> factory class? What does it take? What does it return?<br>
</div><div><br>
><br>
> Factory class proposed by whom and for what?<br>
<br>
</div>I think that was you, and I think it was for gluing the classes in<br>
NMEA together. From your mail on July 30:<br>
<br>
> 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.<br>
<br>
I'm not sure what a factory that takes a factory is.</blockquote><div> </div><div>That was a typo. There should be a <i>method</i> which nicely hooks everything together and takes only a factory (etc).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'd think it's something that implements IPositioningProvider (eg a class) and then
returns the instance?</blockquote><div><br>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".<br>
<br>On the other hand, you could just have the class classProvides() the factory interface and implements() the main interface for convenience, since a class <i>is</i> really a factory in Python.<br><br>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()<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Would this be the correct place to implement behavior like "listen on<br>
a bunch of serial ports, until you find something that spews things<br>
that look like NMEA at you", or should that be another level of<br>
abstraction up?<br>
</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Would there be multiple such factories for different kinds of<br>
positioning? I don't know what cell ID will need to know to set up an<br>
IPositioningProvider, but the NMEA factory and gpsd factory need<br>
completely different kinds of information, for example.<br></blockquote></div><br>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<br>
<br>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.<br>
<br>