RFC: civic location

[Jussi Kukkonen]

Thanks for the comments. I assume you intended to reply to the list, and
will quote most of it here...

keith preston wrote:
>> * Is Civic location an interface of it's own or should the
>>   functionality go into Positioning-backends? I originally thought a
>>   new backend type would be good idea, but am not 100% sure anymore...
>>   Some reasons for using a new interface:
>>     * the api might get fairly large (see below)
>>     * a lat/lon source is not necessarily a civic location source
>>       (and e.g. selecting GPS as the default backend would mean no
>>        civic location)
> 
> 
> This was originally why I had a geocoding API.   I feel that it might also
> be useful to add to the position API.   I'm not concerned about the API
> getting large, as long as they are useful.   We can always implement an
> error code that states that the backend does not implement the specific API
> function.

My opinion on this is not that strong, and I admit my experience with
dbus services/interfaces is pretty shallow.
 Still, aren't we diminishing the meaning of the interface if we combine
them? If a backend implements an interface, it should IMO be able to
offer what the interface promises (that's a simplification of course,
but you get the idea). That is what an interface is after all -- a
promise of functionality.

 I guess it is possible to implement several interfaces with one backend
in dbus? This way the number of backends (or code) wouldn't really rise.
Something like this:

  Backend   |  Implements
  ----------------------------
  gps       |  lat/lon
  hostip    |  lat/lon, civic
  manual    |  lat/lon, civic

I admit that off the top of my head I can't think of other backends than
GPS that would only implement one interface -- if it really is the only
one, then I've just been nit-picking for two posts...

>> * The API. Currently my prototype is very spartan, only one method
>>   (and the hostip implementation actually only fills country and city):
>>
>>       current_location (country, city, street, house_number)
> 
> 
> I would shy away from another complete API with only one method.

Heh, it was not intended to be my suggestion for an API, I was just
getting RSI from writing the (nearly) same things too many times...
 Note to self: should make a backend-template for new backend-writers --
writing a backend was surprisingly easy, but it would be a lot faster if
there was a template.

>>
>> [clipped table from rfc 4119]
>>
> 
> You could also have a method that just gives back a "human readable string"
> rather then all the separate parts.   This allows you to display the end
> result to the user.   It also allows a backend that supports manual input.
> So the user could set there position to "The Library on 6th Street, Boston,
> Mass".   

Yes, definitely a good idea.

> * Combining / standardizing interfaces
>>   This is how we use/produce location info right now:
>>     * position                    IN: -           OUT: lat/lon
>>     * geocode (addr_to_latlon)    IN: civic       OUT: lat/lon
>>     * geocode (latlon_to_addr)    IN: lat/lon     OUT: civic
>>     * civiclocation               IN: -           OUT: civic
>>   We should probably make sure that at least the interfaces that have
>>   the same output types have the same interface (as much as possible).
>>   Other ideas? Is the current interface division a smart one?
> 
> 
> I think the division is up for discussion.  You could ask my opinion, but
> you can already see it in the existing code.   I'm up for changing with
> compelling reasons.   If anything I think a current location could be added
> to the position API, because many position backends will support this (host
> ip)

I'm not entirely sure what I'd like to happen, but the reasons I brought
it up were A) the interface "meaningfulness" issue I mentioned and B)
for pointing out the need for consistency -- we should keep e.g.
geocode_lat_lon_to_address API and civiclocation API (wherever it is
put) methods and outputs as similar as possible.

>> * backends using other interfaces/backends
>>   It's possible (and probably smart) to write backends that use
>>   other backends to get the data. Example:
>>     A civiclocation backend uses the position interface (e.g. GPS
>>     backend) to get lat/lon and then the geocode interface (e.g.
>>     yahoo backend) to get civic location.
>>   Is this a good idea? Is there anything preventing this?
> 
> I don't quite know about the proper way for interaction.    I prefer to
> define the interfaces as a raw information source and leave some of the
> combination aspects to the client programmer.    If need be, I think we can
> provide a wrapper C library, that implements some higher-level
> functionality.

You are probably right, shouldn't overengineer. This is not a high
priority issue anyway.


Thanks for the comments again, nice to get some feedback after figuring
out things alone :)

 -jussi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/geoclue/attachments/20070616/0347a598/attachment.pgp