Ok, here are my thought. Just an FYI, but I wrote most of the code and Jussi did the rest. As a note, I met I believe the Head Marble developer at akademy and he showed me the marble project.<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>1. What is the status of the GeoClue project? My impression is that it's in a<br>pretty early phase. Andrew writes that the DBUS protocol is stable, but that<br>is not the impression that I get from the mailing list. For instance, I saw
<br>a remark that somebody wanted to commit quickly so that his API isn't broken<br>again before he gets the chance.<br><br>Can we trust that if we implement support for GeoClue that we won't have to<br>change it later? Additions is not a problem, but we don't want millions of
<br>users to have their system break because the API / protocol wasn't correct<br>the first time. A way around this might be to introduce a protocol version.<br>Future versions of Marble can then query the GeoClue server for the protocol
<br>version and adapt to it.</blockquote><div><br>The status of the Geoclue project is that it is just entering the Beta phase for the positioning API as of a few days ago. Although we are not guaranteeing ABI and API<br>
for right now, they should be very stable. I expect us to declare a stable ABI API in probably a few months. A note for other geoclue developers, I've been working to replace the GPSD backend. I have contacted the author of another project GYPSY about integrating his NMEA parser dbus backend with Geoclue. Once this is done and any remaining problems are worked out, I believe we will be stable for the position API.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2. On the wiki, you mention a number of services that you want to support.<br>
Right now, the most interesting of them is Positioning. What is the status<br>of the various services regarding stability (design and implementation)?<br><br>I see some problems with frontend - backend separation here... Surely the
<br>backend is not supposed to propose Routing between positions? Isn't that a<br>natural feature of an application? Also, what is the 'Map' service supposed<br>to be? I couldn't find any real explanation for it on the wiki.
</blockquote><div>Sorry, the wiki is out of date. Geoclue is designed to be a DBUS service protocol definition of geographic data. Obviously position is the most obvious and the first that we are completing. The second was going to be the 'Map' service. If you look at it, it is a rudimentary way to grabs maps of location. I hacked up a simple backend that fetches maps from yahoo maps. Marble, might qualify for a nice Map Backend for geoclue in the future, depending on how that API develops.
<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3. Regarding settings: This is a project hosted on the <a href="http://freedesktop.org">
freedesktop.org</a> server.<br>You also mention that you want this to be a cross-desktop backend (something<br>I agree with very much). Yet, I see several mentions of storing settings in<br>gconf, the Gnome configuration storage. I must confess my ignorance here,
<br>since I don't know how other <a href="http://freedesktop.org">freedesktop.org</a> projects handle this issue, but<br>to me that sounds like a pretty *non*-cross desktop solution. Also on the<br>mailing list, I see no mention whatsoever about contacting KDE people, but
<br>several mentions of Gnome and Guadec. Now, I know that we/you have to start<br>somewhere, but if the intention is truly cross-platform compatibility this<br>issue must be dealt with.</blockquote><div><br>Granted this generally started as a gnome friendly project, but we are open to other solutions. We currently use gconf and the dbus-glib bindings. However there is quite a bit of portability in KDE to use the glib mainloop. I sure if we had enough interest we could maintain a QT bindings. Technically these are not requirements on the client, but only the backends. Client can purely use DBUS to access us (we are looking into some python application currently)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4. Also regarding platforms: Marble, and I imagine other applications, are<br>
already portable to not only Linux, but other Unix-like systems and also<br>Windows and Mac OS X. We cannot depend too closely on solutions that are too<br>platform-specific. What is the status of GeoClue in this regard, and what
<br>are the plans for the future? Is there a roadmap?</blockquote><div><br>We have no roadmap about other operating systems. Currently we would have to have dbus support on that platform, and enough users to test if our backends functioned on that platform
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">5. Downstream: What relations does the GeoClue project have with the Linux<br>
distributions and people on other platforms? Is there or will there be<br>binary packages of GeoClue? If there will be, do you know when?</blockquote><div><br>We haven't quite got established yet in the downstream. We are currently working toward integrating with some Apps first and then expanding.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ok, that was a lot. Don't get me wrong here; I think GeoClue is a good idea,
<br>and it would be a very natural backend for Marble if it was already<br>established and stable. I think it would be a good idea if you could release<br>something small with just the positioning service pretty soon and also
<br>introduce some forward compatibility by using version numbers for the<br>protocol.<br><br>Best regards,<br><br>Inge Wallin<br>The Marble Team<br></blockquote></div><br>