gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: teyrana
Subject: Re: [gpsd-dev] [RFC] python client patch - reconnect to gpsd
Date: Fri, 9 Mar 2018 18:43:15 -0500


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

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? 

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)
 


> 2. I've made an effort to keep the python function API backwards
> compatible.  Please let me know if anything is missing.

Well:

    # Don't hand-hack this list, it's generated.

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

To be direct:  I don't see any generation code.  AND, given that we've checked the constants into version control, it's obviously not generated very often.  Can't we just point the generator at the new file? 
The comments don't mention *how* that list is generated.... so.... I don't know where to coordinate those from.

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

 
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]