[Marble-devel] Marble and GeoClue - the dynamic duo?
jhkukkon at cc.hut.fi
Mon Aug 20 22:55:45 CEST 2007
I'm a bit busy today, but here's my 2c.
> 1. What is the status of the GeoClue project? My impression is that it's in a
> pretty early phase. Andrew writes that the DBUS protocol is stable, but that
> is not the impression that I get from the mailing list. For instance, I saw
> a remark that somebody wanted to commit quickly so that his API isn't broken
> again before he gets the chance.
Keith just did some position API rewrite work. Let me put it this way: I
wouldn't release a geoclue client application this week -- the internals
aren't 100% in shape yet and I believe we should take a long hard look
at the position API at this point: Like you said getting it right is
That said, I'm fairly happy with the public API now and I'd say it's
very close to being finished (changes are not going to be difficult for
> 2. On the wiki, you mention a number of services that you want to support.
> Right now, the most interesting of them is Positioning. What is the status
> of the various services regarding stability (design and implementation)?
The wiki really needs work... My personal opions on the matter:
Position: Design is stable (minor changes possible in next weeks).
Several position provider implementations are stable or
close to it, although not widely tested.
IMO Position API and a small set of position providers is
priority number one. I'll be working on stabilizing this in
the near future.
Other APIs: states vary between "just an idea" and
"works, but needs API rewrite"
> I see some problems with frontend - backend separation here... Surely the
> backend is not supposed to propose Routing between positions? Isn't that a
> natural feature of an application? Also, what is the 'Map' service supposed
> to be? I couldn't find any real explanation for it on the wiki.
In my opinion the map API/providers belong to the group "works, but
needs API rewrite". If we have a map provider it should return just
images, not include GUI parts like it does now.
> 3. Regarding settings: This is a project hosted on the freedesktop.org server.
> You also mention that you want this to be a cross-desktop backend (something
> I agree with very much). Yet, I see several mentions of storing settings in
> gconf, the Gnome configuration storage. I must confess my ignorance here,
> since I don't know how other freedesktop.org projects handle this issue, but
> to me that sounds like a pretty *non*-cross desktop solution.
gconf doesn't require Gnome and although gconf does have some
gnome-related dependencies (oaf, orbit), I believe the total footprint
is fairly small.
Anyway, I'd have no problems using another config system (replacement or
additional). If the system has a callback system for watching changes
this should be easy.
> 4. Also regarding platforms: Marble, and I imagine other applications, are
> already portable to not only Linux, but other Unix-like systems and also
> Windows and Mac OS X. We cannot depend too closely on solutions that are too
> platform-specific. What is the status of GeoClue in this regard, and what
> are the plans for the future? Is there a roadmap?
If we forget the Map API for a while, I'd say Geoclue looks pretty
portable. As long as the platform has an implementation of D-Bus, no
large changes should be needed.
> 5. Downstream: What relations does the GeoClue project have with the Linux
> distributions and people on other platforms? Is there or will there be
> binary packages of GeoClue? If there will be, do you know when?
Bergie mentioned the Maemo packaging: I'm just finishing that. The
packaging itself is almost 100% usable on Debian and Ubuntu, but there's
no configuration UI for desktops yet so I haven't bothered so far...
> Ok, that was a lot. Don't get me wrong here; I think GeoClue is a good idea,
> and it would be a very natural backend for Marble if it was already
> established and stable. I think it would be a good idea if you could release
> something small with just the positioning service pretty soon and also
> introduce some forward compatibility by using version numbers for the
The APIs have a version number, but that hasn't been used yet -- I
assume because there hasn't been a stable API until now (Keith can maybe
explain his ideas on this)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/marble-devel/attachments/20070820/afbd5b64/attachment.pgp
More information about the Marble-devel