summaryrefslogtreecommitdiff
path: root/www/future.html
blob: 94eed664d100b6f6873bbb8873a4d7a1f272f82a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Remco Treffkorn">
   <meta name="Description" content="GPSd is a utility that can listen to a GPS or AIS receiver and re-publish the positional data in a simpler format.">
   <meta name="Keywords" content="GPS, translator, mxmap, GIS">
   <link rel="stylesheet" href="main.css" type="text/css"/>
   <title>Future of the GPSD project</title>
</head>
<body>

<div id="Header">
Future of the GPS project
</div>

<div id="Menu">
    <img src="gpsd-logo-small.png"/><br />
    <a href="index.html">Home</a><br/>
    <a href="index.html#news">News</a><br/>
    <a href="index.html#downloads">Downloads</a><br/>
    <a href="index.html#mailing-lists">Mailing lists</a><br/>
    <a href="index.html#documentation">Documentation</a><br/>
    <a href="faq.html">FAQ</a><br/>
    <a href="xgps-sample.html">Screenshots</a><br/>
    <a href="index.html#recipes">Recipes</a><br/>
    <a href="index.html#others">Other GPSDs</a><br/>
    <a href="hardware.html">Hardware</a><br/>
    <a href="for-vendors.html">For GPS Vendors</a><br/>
    <a href="wishlist.html">Wish List</a><br/>
    <a href="hall-of-shame.html">Hall of Shame</a><br/>
    <a href="hacking.html">Hacker's Guide</a><br/>
    <a href="references.html">References</a><br/>
    <a href="protocol-transition.html">Application Compatibility</a>
    <a href="history.html">History</a><br/>
    Future<br/>

    <div>&nbsp;</div>

    <a href='http://www.catb.org/hacker-emblem/'><img
    src='http://www.catb.org/hacker-emblem/glider.png'
    alt='hacker emblem' /></a><br />

    <script type="text/javascript" src="http://www.ohloh.net/p/3944/widgets/project_thin_badge.js"></script>

    <hr/>
    <script type="text/javascript"><!--
    google_ad_client = "pub-1458586455084261";
    google_ad_width = 160;
    google_ad_height = 600;
    google_ad_format = "160x600_as";
    google_ad_type = "text";
    google_ad_channel = "";
    //--></script>
    <script type="text/javascript"
      src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
    </script>
    <hr/>

    <a href="http://validator.w3.org/check/referer"><img
          src="http://www.w3.org/Icons/valid-xhtml10"
          alt="Valid XHTML 1.0!" height="31" width="88" /></a>
</div>
<div id="Content">
<p>This page is our roadmap for future features and releases.</p>

<h2 id="new_protocol">The new GPSD protocol</h2>

<p>2.90 has shipped, and with it the redesign of GPSD's wire protocol.
While this brings many benefits (including, immediately, the ability
to interpret and report on the output of marine AIS receivers) it
poses some significant deployment challenges as well.</p>

<p>Over the next few releases we're going to be preoccupied with 
<a href="protocol-transition.html">managing the transition to the
new protocol.</a>. See that document for our tentative release schedule:</p>

<p>For more on specific tasks planned for upcoming releases, see our
<a href="TODO">file</a>.</p>

<h2 id="hosting">Changing hosting sites</h2>

<p>We're presently (April 2010) hosted at <a
href="http://developer.berlios.de">berlios.de</a>, but find that it
has become extremely flaky of late (logins failing due to broken SSL
certs is the most recent symptom).  We plan to change sites some time
in 2010.</p>

<h2 id="buildsys">Changing build systems</h2>

<p>Our build is presently autotools-based. We may move to scons in
2010. Autotools is a festering pile of hacks, and will become a
serious liability if David Ludlow's Windows port actually
finishes.</p>

<h2 id="dbus">Delegating DBUS support to geoclue</h2>

<p>We're going to stop shipping DBUS notifications directly at some point.  
<b>Note: This is no longer a near-term prospect, as geoclue is reported
not sufficientrly stable to bear the weight.</b></p>

<p>The reason for this is <a
href="http://www.freedesktop.org/wiki/Software/GeoClue">GeoClue</a>.
GeoClue is an aggregator that takes geolocation-related information
from provider programs, including <code>gpsd</code>, and publishes
it on DBUS.</p>

<p>For us, DBUS support is a dusty backwater in our code.  We don't
track what the DBUS community is doing or expecting.  Our devteam
worries about version skew between GPSD's DBUS transmissions and
client apps, and wouldn't have the knowledge base to fix that quickly
if it happened.</p>

<p>The GeoClue team, on the other hand, loves DBUS and specializes
in it. We think it's probably best for both projects if they take
data from us and handle the DBUS publishing job for us.</p>

<h2 id="api_cleanup">Client API cleanup</h2>

<p>This is not a near-term project.</p>

<p>The client API has some historical baggage, unfortunate naming, and
scar tissue in it.  At some point we're going to bump the API major
version number to 5 and make the following changes:<p>

<ul>
<li><p>gps_open_r() will be renamed to gps_open(). The existing
gps_open() will go away.</p></li>

<li><p>The 'waiting' and 'buffer' members of privdata will move into
the public part of gps.h</p></li>

<li><p>gps_set_raw_hook() will be removed. Instead, clients will simply
be able to look at the packet buffer directly. (Of course, this is
only recommended when the PACKET_SET flag is up.)</p></li>

<li><p>gps_poll() will be renamed to gps_read().</p></li>

<li><p>There will be a new gps_poll() entry point that will perform
a nonblocking poll of the daemon, using the (now experimental) ?POLL
command).</p></li>

<li><p>The message 24 structure may be split into part A and B so these
are in effect separate messages.</p>
</ul>

<p>Client API users will have the API_MAJOR_VERSION symbol available to
conditionalize their code so it will work with any version.</p>

<p>What is most likely to trigger this change is the restoration of
polling as a fully-supported mode in the wire protocol (it is
presently experimental and buggy and <b>not recommended</b> for production
use). At that point, the skew between what ?POLL does and what and
gps_poll() does will become severe.</p>

</div>
</body>
</html>