Just for your information, but Jussi and I had quite a long conversation detailing some of the internal of how geoclue is progressing.   If you are interested read on.   jku: Hey, what are your plans in the next week or two regarding geoclue? Writing the geoclue control UI (a statusbar applet, or panel applet in gnome terms) for maemo revealed several problems I could start solving -- but I don't want to get in the way if you're in the middle of something.... Sent at 10:11 AM on Wednesday me: No, I'm not in the middle of anything right now. What problems are you seeing with the applet? jku: I probably won't remember everything (haven't collected my notes yet), but: 1. the "default provider" idea doesn't work like I expected: Sent at 10:15 AM on Wednesday jku: If I subscribe to a signal from the default provider I'd expect the provider to change when the gconf key changes (so new provider signals are now received) Matter of opinion I guess, but that's what my use cases would want 2. get_all_position_providers isn't working Sent at 10:17 AM on Wednesday jku: 3. I'm having problems with getting a valid userdata-pointer from the signals (this could be a bug in my code though) Sent at 10:19 AM on Wednesday jku: 4. civic location signals do not have timestamps (I guess they should, at least for consistency) Sent at 10:20 AM on Wednesday jku: 5. (this is probably my fault) one of the civic location callbacks / methods has a bit different signature from the rest -- it works but is unexpected Sent at 10:23 AM on Wednesday jku: That's about it, I guess Sent at 10:24 AM on Wednesday me: hmm.. yeah there is a little work jku: What's your take on #1 me: for the get_all_providers, we need to move the code from the old geoclue master to the C client library for the default provider, we need to implement geoclue master, it's nowhere to be seen. All it really needs to do, is implement the position api and forward out calls (could even use the client library itself) to a backend based on a gconf key, or what ones are available jku: yes, agreed me: I know the signal problem. Let me commit some code, one sec Sorry, I forgot to commit it when I was correcting a few things. Since now we dont catch the callback in the library and then pass them on, the parameters are different. gobject signals what to add the gobject pointer to the front of them. so it is signal(gobject, parameters..., userdata) jku: ok, good me: I remade the callback typedef to have a void* unused at the beginning, that fills in for the the gobject pointer. it's useless to clients, but always gets marshalled in. Sent at 10:32 AM on Wednesday jku: I'll take a look. About get_all_providers: do you mean that the C wrapper should scan /usr/local/share/geoclue/backend like master does now? Or what was the idea? me: Yeah, that's the idea I think that is easiest. Sent at 10:34 AM on Wednesday me: I think I've been getting an idea on the signals for position.   I liked your idea of filtering. It would be hard to give a few paramters to the position signal and then internally filter them. jku: would or would not? me: That way the backend can signal all they want (like a gps that keep broadcasting the same position, but with new timestamps.) would not we could have a timestamp filter, and a position filter.   I'll probably add that next time I start hacking. jku: sounds good Sent at 10:37 AM on Wednesday jku: about timestamp: what do you think it should be for webservice backends? I'm thinking it's just current time (even if the query may have been done hours ago when the current internet connection was made) since it's going to be correct 99% of the time There should maybe be a a timer the requeries after some hours, but basically I think we can trust hostip and plazes location fo as long as the connection is up s/timer the/timer that/ Sent at 10:40 AM on Wednesday jku: so what was wrong with the previous implementation of get_all_providers? It C wrapper asked geoclue_master IIRC.. me: Webservice timestamp should be the time that it contacted the webservice (usually now) jku: on maemo I have libconic that tells me when connections start and stop, so I only query when a connection is made me: yeah, then that timestamp is when the connection started and the service was quieried jku: agreed me: I don't like that you contact a dbus service that just reads files directly. jku: ? me: I don't think geoclue master should have any specific API at this point, it should just be a proxy for filter between multiple backends. so that like was about geoclue-master my typing is horrible today jku: [smile] me: (sorry that line was about geoclue master) Sent at 10:49 AM on Wednesday me: DBUS is a nice abstract thing, but I am realizing it can be slow, so if you can do something easily yourself, then you can avoid DBUS , ( i.e. the get_all_providers) jku: IPC tends to be slow, yes me: oh yeah, just a note, but if you take a crack at geoclue master, there is a slight trick.   to do a sychronous DBUS call inside a synchrounous DBUS call you need some thread tricker and private DBUS connections. jku: but I can't imagine get_all_providers or get_default_provider is done so often that it's a problem? me: trickery Yeah, it's not a speed issue, it is more that I don't like what geoclue master is currently doing and I've reenvisioned it as a proxy. Previously, I saw it as somehting you connected to to find out who to directly connect to. Now I see it was someone who mimics teh api of the other backends and proxies to them based on .....magic..... jku: yes, exactly magic is the word I was looking for... me: Does that make sense? magic... really just means an algorithm To Be Determined. jku: Oh it makes sense. Absolutely. The problem is that then geoclue really needs bindings... even on languages that have easy dbus access Because otherwise you need to know about gconf keys and files in /usr/local/share/geoclue/backend...' me: we typically, unless you want to check for a specific provider and use it directly you shouldn't need _get_all_position_providers. That is really for advanced people that want to do weird things. jku: yes, you're right me: I figure the only apps that will ever use that might be our example apps. Like we have an app that connects to every availble backend and displays it's current status. Otherwise, you should just connect to geoclue master and be done with it. It it is necessary, we can add it back later, but I don't think it will be. jku: ok, true. My configuration UI is a special case. Sent at 10:58 AM on Wednesday me: Yeah probably, the configuration should become automatic(ok, mostly automatic) with geoclue master Maybe for now the gconf default key can just be the Hint to geoclue-master which to check first. Sent at 11:00 AM on Wednesday jku: ultimately there needs to be a preference list. I have a feeling that getting geoclue-master magic working nicely is going to be a lot of work... Sent at 11:03 AM on Wednesday me: Yeah, maybe configuration can just be a preference list,   I kind of like that idea.. use  GPS, hostip and then manual..... Sent at 11:06 AM on Wednesday jku: I'll have to go. I'll probably move the  get_all_providers code to the wrapper soon, so I can dynamically create the provider menu in my UI. me: ok, it might be good to post this conversation to the list Are you ok if I do this? jku: and add timestamps to civic location signals/methods Go ahead. While you're at it, answer the guy who asked about get_all_providers [smile] me: hmm, I didn't see that but I'll check again.