Upcoming feature freeze

[Hal Murray]

> #55: ntpd refclock GPSD_JSON just stops working.

I haven't noticed any troubles.


> If any of you have an interest in saving this driver, step up now and fix
> it. 

How important is supporting gpsd on systems without SHM?

I think we need the concept of stability to be associated with various 
features.  There should be a way to ship something without a promise of long 
term support or that it will run on all systems or that all combinations of 
options have been tested or ...

-------------

This whole area needs a lot of thought and work.  I assume that is on the 
post 1.0 list.

Is anything written down anyplace?  Where?  How does SHM/JSON interact with 
the great refclockd proposal?

We could fix the ntpd side of the SHM interface to be read only.  That would 
let multiple readers listen to the same source so you could fire up shmmon 
while ntpd was running.  I think this would solve a protection problem.

Some systems don't have SHM.  Do we have a list of those systems?  Do we need to support external refclocks on those systems?  Are we using POSIX SHM?  (How many SHM variants are there?)


Would you be happy if we threw away the current code and you started from scratch?  Would it help if the JSON interface was NTP centric rather than GPSD centric?  Maybe we should make a JSON-JSON translator to go between gpsd and ntpd.

It would be nice if there was a clean interface for external drivers.  I assume that each current driver would turn into a stand alone program that talked to ntpd via some new/wonderful interface.


-- 
These are my opinions.  I hate spam.