On Thu, Jul 30, 2009 at 8:26 AM, Laurens Van Houtven <l...@laurensvh.be>wrote:
> On Thu, Jul 30, 2009 at 3:01 AM, Glyph Lefkowitz<gl...@twistedmatrix.com> > wrote: > > I've attached a sketch > Extremely helpful, thank you. You're welcome. > 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 > :-) > Does it also bother you that 'dataReceived' delegates to 'lineReceived'? :) What exactly would those > > startReceivingNMEA/stopReceivingNMEA/startReceivingPositions/stopReceivingPositions > 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. > Right? > You don't need to do anything at all in these callbacks. The important point is to provide them, so that applications which, for example, wish to show a little "GPS active" icon will know when data starts and stops arriving. Also important so that an application can re-connect or re-initialize the device or whatever, without hooking implementing multiple interfaces and hooking in at multiple levels. Given that data for positioning may come from a variety of sources it's important to have a positioning-specific method that marks the start and stop, rather than depending on connectionMade or similar. One could for example imagine a hypothetical HTTP-polling-based positioning provider which would have a connectionMade for every sentence of data, but that wouldn't represent a start and a stop at the positioning level. start would simply be called before the first position, and stop would be called after a timeout or after certain varieties of HTTP error.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
