Re: [gpsd-dev] [RFC] python client patch - reconnect to gpsd

[Gary E. Miller]

Yo teyrana!

On Fri, 9 Mar 2018 18:43:15 -0500
teyrana <address@hidden> wrote:

> >
> >  
> > > This patch enables the python client-side libraries to reconnect
> > > to gpsd: 1 .This behavior is off by default, and is enabled by
> > > passing 'reconnect=True' into the gps( ... ) constructor.  
> >
> > Most people are not gonna want to patch the code.  Maybe add CLI
> > options to cgps, xgps, etc.?
> >
> > I'd be tempted to make the new behavior the default.  This is an
> > issue that has long annoyed people.
> >
> >  
> 1.  Hey, I'm okay making this the default.  I did want to offer
> people the option, but if no one really wants the other option,
> great!  That makes things easier.  Would people still want the CLI
> options for cgps, etc if 'reconnect' is the default behavior?

I think to start it has to be default off.  Our users hate change, and
don't read change logs.  Thus the need for the CLI option as our
users almost never ever touch code.

> > How does the user know if he is in disconnected state? cgps and xgps
> > should notify the user somehow, so he does not wait forever
> > thinking his connection to gpsd is up.
> >
> >  
> 2. Currently, our application code just times out on the last valid
> gps update, because that's a more general failure mode.  I'm not
> particularly concerned about fast response time, so I'm okay with
> that tradeoff.

yes, but how does the USER know this?

> But if the community has concerns, I could have the library raise an
> error on failure-to-connect, or just have a 'gps.is_connected'
> property to check. Thoughts?

I do not think it is an Error, certainly a warning.

> The failure modes I commonly see are:
> - gpsd is up, but hardware is not.  (eg. unplugged or broken)
> - gpsd has errors (e.g. could not bind to its port)
> - gpsd is operating fine, but not reachable (e.g. network or firewall
> issues)

The reconnect only affects the last one.

> > I don't see any changes that move the generation from the old place
> > to the new.  Did I miss something?  To me this is the blocker, how
> > does that generation now work?
> >
> >  
> 3.
> Well, gps/options.py now has those constants: it was simply moved
> from: a. gps/client.py:127
> b. gps/gps.py:30

Correct, but it WAS autogenerated at one point.  Mayb that is now broken,
m,aybe not, but your patch definitely breaks the automation.

> To be direct:  I don't see any generation code.

I've seen it.  If it is broken, it needs to be fixed.

> Can't we just point the generator at the new
> file?

Taht would be my approach.  have at it.

> The comments don't mention *how* that list is generated....

Yeah, your comments will be WAY better.

> The other option would be to simply defined those constants in
> gps/gps.py, and important them from there.

What ever works, given our vague contraints.



RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpmgZYIyIiDh.pgp
Description: OpenPGP digital signature