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 _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
