[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-dev] SHM tangle
From: |
Hal Murray |
Subject: |
[gpsd-dev] SHM tangle |
Date: |
Mon, 16 Feb 2015 15:00:11 -0800 |
I suggest backing out of the in-use change and leaving the current SHM code
to rot. It works. Please don't risk breaking something.
There is a meta issue with that change. You are assuming that you own that
API. You are making a change without consulting users. There is probably a
meta-meta issue in that we don't even know who the users are. Yes, the
change might make sense for gpsd. But somebody else might use similar
reasoning to make a conflicting change.
My suggestion is to abandon the old SHM mode and design/implement a new one.
At the same time, we can update JSON to correctly handle time. Or perhaps
JSON is the clean interface and we should abandon SHM.
Inventing a new scheme avoids compatibility problems.
My rough outline for a new SHM:
The API would be owned/managed by the gpsd project.
(it would be nice if they kept track of and coordinated with users)
The SHM key would be GPSx
The SHM segments would be read only to clients.
(so multiple readers would work)
ntpd can use a mode bit to select the new/old SHM interface.
If another project comes along, they can invent their own or clone the GPSD
scheme, changing the key to avoid conflicts.
--
These are my opinions. I hate spam.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gpsd-dev] SHM tangle,
Hal Murray <=