> #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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
