Future of location services on OM

[Stefan Schmidt]

Hello.

On Thu, 2009-01-15 at 00:18, Onen wrote:
> 
> Stefan Schmidt wrote:
> >
> > Great. What interface do you use for this? Already the new monitor interface?
> >   
> Well, no. Would you mind pointing me more precisely what you are talking 
> about? I use code similar to the examples you find in the 
> /usr/share/freesmartphone/examples files. That is to say, 
> org.freedesktop.Gypsy interfaces (GetPosition, GetCourse).

It's a GSM monitor for cell informations. Also neighbour cells. And yes, you got
us. Not documented API until now. Mickey fixed it:

http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.Monitor.html;hb=HEAD

> > Seriously, if you come up with some ideas and  code for something like olocationd
> > we would appreciate it.
> >   
> I am not aware of this, I cannot find it in the FSO API documentation. 
> Where can I find some more information?

I used olocationd as a synonym for what you will create. It does not exist yet,
neither the docs.

> > Once you have a recipe ready we can put it into OE, build it and put it into the
> > feed.
> >   
> Ok. So far I had a quick look at the way to build an opk package. I will 
> look at this afterwards.

Sure, just ping me if you have something you want to integrate into the feed.

> > IIRC the new monitor interface should give you the needed infos. Jan just put
> > some code into zhone to demonstrate the usage. It's python, check it out.
> >   
> I have noticed that things were coming on this side. But first release 
> the basics.

Jup, Release early and often. No need to make everything in one release.

> >> * another application using the openBmap database located on the phone, 
> >> to get location ( I have a quick look at rocinante, it seems you guys 
> >> already built something for use inside TangoGPS. Would be nice :-) ). 
> >>     
> >
> > I'm more in favor of navit as it is real navigation and not only displaying
> > images. But that's a matter of taste.
> >   
> I was referring to the fact that I could use their code to do something 
> similar. But what I have in mind is to provide a dbus service, providing 
> GSM based location. Now I think I understand what you meant above in 
> your mail, about integration in FSO. Is it what you had in mind?

I was thinking along these lines, just thinking , no code or descision:

* ogsmd offers the MCC/MNC/LAC etc informations via dbus, no need to duplicate
this.
* What different _does_ you offer? Location from GSM.
* A dbus interface that gives you the name of the city or even the district with
  zero extra costs like tunring on the GPS would be nice.
* You could offer the appr. GPS coordinates from the db. How would we integrate
  this? Some dummy GPS device?
* We want for sure use this when we power up GPS to set the appr. location so we
  can get a faster fix.

This kind of stuff I would like to see as a service via dbus. Prefered would be
a subsystem in FSO. This would fit into a framework as it provides data that
different applications can use.

> > Well, I would not put to much into the application itself. We have a framework
> > you improve to your own needs. That's really different from other systems, make
> > use of it! :)
> >
> > Meaning, I would put the logic and the communication with the webservice either
> > in a fso subsystem or in a small daemon process. Eyporting a nice API will allow
> > more then one app to make use of it.
> >   
> Ok, then we have the same thing in mind :-)
> 
> I was thinking about Tichy in the way of plugins:
> * one tichy plugin which provides let's say GPX files
> * one tichy plugin which gathers GSM and package this with GPX
> * one upload plugin
> * one plugin which updates the local database
> * one tichy plugin which provides GSM location,

Tichy plugins are for the user interface part. I would put none of the above
into it. That's what we have the framework for.

> * one plugin which consumes it.

That could be the right place for a consumer.

With this method all the goodies would also be available to SHR or other
applications in an easy way.

> My main point was providing a GSM location service, embedded in the 
> phone. I love my privacy (no need to ask any third party on the Internet 
> where I am located ;-)), and my battery (GSM is on all the time anyway, 
> GPS needs quite a lot of power, plus waiting for the fix).

Good thinking. Just work on your current code and make a release. People can
play with it and you can come up with other interested people and work on
putting it into the framework.

regards
Stefan Schmidt