implement org.freedesktop.Geoclue.Position iface for localnet ?

[Jussi Kukkonen]

arno wrote:
> Hi,
> currently, localnet only provides addresses.
> I'd like to have something similar (a simple config file, and an api to modify 
> it from other softwares) for positions.

Hi arno,

Great to hear that. I'll first tell you why I originally wrote localnet 
and manual providers and what I think we should do with them -- please 
comment if you have other ideas.

The use cases for this include
* a panel applet that shows the current location (from master) and a way 
to correct it: a text entry and/or a map widget.
* twitter client that uses geoclue but lets user correct the location

The basic needs are:
1. We want to let users define their location manually, possibly from
    several applications
2. This manual input must be able to override other sources
    (so users can correct wrong location info)
3. we should "save" this manual info for later use
    (based on MAC address, possibly other things)
4. saved info must be easily modified/erased

Originally I only implemented Address interface in manual & localnet, 
but I do agree Position should be covered as well: clicking a location 
on a map is obviously a use case for that.

That said, I'm not at all sure the current implementation in 'manual' & 
'localnet' is good: They were quite ad-hoc -- this is the reason there's 
no real documented API for them... It might make sense to evaluate the 
design now and define a proper API if you want to do some work on this.


Some questions/ideas:

* Do we need separate 'manual' and 'localnet' providers? I'm starting to 
think we don't: the "valid_for" property in manual didn't turn out to be 
useful, and if we remove that the functionality is very much covered by 
localnet already... The provider name could be better, like "user-set" 
or something.

* User provided information should probably trump even more "accurate" 
other providers, when master selects current provider. I guess this 
could be done with e.g. a flag in .provider-file?

* Currently localnet works based on MAC address. Are there other things 
we could use? We should also probably start looking at the type of the 
network we're on: I assume this method is not a very good one on a GSM 
data connection for example.

* When defining the API for setting a manual position, make sure it's 
possible to remove the manual position as well.


> So, I have a few questions about it:
> 
> first, are you interested in including that in geoclue code ?
> If so, I'll try to make a clean patch; otherwise, I can just make something 
> quick and dirty that works for me.

Yeah, absolutely. I think Position should be covered by a "saved 
locations"-provider (localnet).

> then, do you think that should be a standalone provider, or do you think it's 
> better to extend localnet ?

Extend is my opinion.

> If it's better to extend localnet, how to store the position information ?
> If I use another file, what filename should I use ?
> If I use the same file, mac addresses are the group names of mac addresses, so 
> I don't think I can have different groups for positions and addresses.
> 
> If I put all the informations (positions and addresses) in the same groups, 
> the property name "accuracy" will conflict.
> 
> So, what do you think is best ?

The whole keyfile approach was part of the "throw something on the wall 
and see if it sticks" approach: Feel free to question even that...

If a keyfile seems like it's good enough, using a single group per MAC 
sounds good to me. Preventing the name conflicts shouldn't be hard, just 
use "position-accuracy" or something (not that it's necessarily needed: 
I think address accuracy should be inferred from the address data).


One related note: I think a "ReverseGeocode.freeform_to_address()" would 
be very useful addition in combination with localnet. Think about the 
Twitter client example:
  * user inputs something like "Helsinki"
  * the app uses freeform_to_address() and then saves the received
    location with localnet


- Jussi