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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>FoxtrotGPS roadmap</title>
<link rel="stylesheet" type="text/css" href="base.css">
</head>
<body>
<h1 class="title">
FoxtrotGPS:
we can dance if we want to...
<img width=56 height=46 src="foxtrot.png" alt="[ft]">
</h1>
[ <a href=".">Home</a> ]
[ <a href="doc/foxtrotgps.html">Manual</a> ]
[ Roadmap ]
[ <a href="faq.html">FAQ</a> ]
[ <a href="build.html">Build</a> ]
[ <a href="https://bugs.launchpad.net/foxtrotgps">Bugs</a> ]
<hr>
<h2>Roadmap</h2>
<p>
FoxtrotGPS intends to be an open platform that fosters
innovation in the community of users and developers, and
everyone is invited to contribute to help guide its growth.
<p>
The initial set of goals, toward which our main focus is
currently directed, revolves around resolving issues in the
current codebase, and is as follows:
<blockquote>
<dl>
<dt>
Integrate <a href="http://gpsd.berlios.de/">libgps</a> [done!]
<dd>
<p>
This was the most urgent issue: rather than using the
<code>libgps</code>
API to communicate with GPS-management daemons, tangoGPS
and FoxtrotGPS rely on using the gpsd-2.x protocol
directly; but, due to severe limitations of this
legacy protocol, gpsd has recently
<a href="http://www.catb.org/gpsd/protocol-transition.html">switched</a>
to using a different and necessarily-incompatible protocol.
<code>libgps</code> provides uniform access to GPS services
using either protocol, as well as insulation against any similar
issues that should arise in the future.
<dt>
Reconstruct the missing GUI-definition [done!]
<dd>
<p>
The GUI implementation inherited from tangoGPS appears
to have been generated upstream from a
<a href="http://glade.gnome.org/">Glade</a> template-file
and consisted of
some ~4000 lines of <em>automatically-generated</em> code.
Unfortunately, the community did not have
access to that template-file, and any customisations that require
adding or changing GUI elements such as menu-items, buttons,
or layout were thus <em>extremely</em> difficult.
<p>
We have converted the GUI to GladeXML.
<dt>
Documentation.
<dd>
<p>
There isn't much, right now:
Daniel Baumann contributed the manpage that he originally
wrote for the <a href="http://www.debian.org/">Debian</a>
package, and we have the standard basic README, INSTALL,
and HACKING documents.
<p>
We need a cohesive user-guide and `quick reference' that can
be installed alongside the application, so that they're
available when the users need them.
<!--
; since FoxtrotGPS is a
GPS and mapping application, it's possible (even likely) that
users will be offline whe they need to consult the documentation...
-->
<dt>
Replace the proprietary `friends' and IM subsystems with
open, standards-based systems.
<dd>
<p>
The location-sharing and messaging features inherited from
tangoGPS rely on a proprietary web-service:
<!--
that appears to
be owned and operated exclusively by Marcus Bauer on
www.tangogps.org
-->
to the best of our knowledge, the code
that drives the service has never been publicly released and
there is no public specification for the service interface.
<em>Theoretically</em>, underspecification and exclusivity
of service-ownership and -operation could also raise
concerns regarding privacy, security, and reliability.
<p>
The best location-sharing option currently appears to be
<a href="http://xmpp.org/extensions/xep-0080.html">XEP-0080</a>,
the location-sharing extension to
<a href="http://www.jabber.org/">XMPP</a>,
which has at least preliminary support in
<a href="http://telepathy.freedesktop.org/wiki/Gabble%20XEP">
Telepathy via Gabble</a>.
<p>
One of the side-effects to expect from opening these
subsystems is that the support for `moving targets' would
become generalised to the point where tracking different
types of `targets' beyond just people would be possible
(examples include things like storms, emergency vehicles...).
</dl>
</blockquote>
<p>
If you can help with these issues, or if you have another issue
that you believe requires attention, please bring it to our
attention on the <a href="http://wiki.osgeo.org/wiki/FOSS-GPS">foss-gps
e-mail list</a>.
</body>
</html>
|