<div dir="ltr">On Mon, Jun 27, 2016 at 2:49 AM, Gary E. Miller <span dir="ltr"><<a href="mailto:gem@rellim.com" target="_blank">gem@rellim.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Since you opened the door...<br>
<span class=""><br>
> |shm        | T     | Shared Memory Driver<br>
</span><span class="">> |gpsd       | T     | GPSD NG client protocol<br>
<br>
</span>I think that leads to confusion since they both, at least for now,<br>
come from gpsd.  And until the gpsd_json driver has sane, documented,<br>
defaults, I fear that people will try it first with gpsd.<br>
<br>
Maybe: gpsd_shm, and gpsd_json.  Or: shm and json.<br>
<br>
There could be other gpsd variants in the future.<br>
<br>
RGDS<br>
GARY<br></blockquote><div><br><br></div><div>I agree with the later comments on shm.  This isn't necessarily specific to GPSD, so just shm is correct.<br><br></div><div>IIRC, GPSD NG uses JSON over a socket.  Is this restricted to GPSD, or is the JSON general enough to be used by any similar source?<br><br></div><div>If the protocol is specific enough that we can assume GPSD, I think gpsd is correct.  I will agree with Gary about the possibility for confusion.  Documentation will help, but the possibility will remain.<br><br></div><div>If this is general enough, it could lead to confusion when another source uses this refclock, but I am unsure of the correct name.  Using socket comes to mind, but that has its own problems.<br><br></div><div>Clark Wierda <br></div></div></div></div>