Conversation

keith preston keithpre at gmail.com
Wed Aug 22 09:11:22 PDT 2007


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/geoclue/attachments/20070822/6e465128/attachment.htm 


More information about the GeoClue mailing list