FoxtrotGPS: we can dance if we want to... [ft]

[ Home ] [ Manual ] [ Roadmap ] [ FAQ ] [ Build ] [ Bugs ]

Roadmap

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.

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:

Integrate libgps [done!]

This was the most urgent issue: rather than using the libgps 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 switched to using a different and necessarily-incompatible protocol. libgps provides uniform access to GPS services using either protocol, as well as insulation against any similar issues that should arise in the future.

Reconstruct the missing GUI-definition [done!]

The GUI implementation inherited from tangoGPS appears to have been generated upstream from a Glade template-file and consisted of some ~4000 lines of automatically-generated 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 extremely difficult.

We have converted the GUI to GladeXML.

Documentation.

There isn't much, right now: Daniel Baumann contributed the manpage that he originally wrote for the Debian package, and we have the standard basic README, INSTALL, and HACKING documents.

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.

Replace the proprietary `friends' and IM subsystems with open, standards-based systems.

The location-sharing and messaging features inherited from tangoGPS rely on a proprietary web-service: 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. Theoretically, underspecification and exclusivity of service-ownership and -operation could also raise concerns regarding privacy, security, and reliability.

The best location-sharing option currently appears to be XEP-0080, the location-sharing extension to XMPP, which has at least preliminary support in Telepathy via Gabble.

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...).

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 foss-gps e-mail list.