keith preston wrote: > Interesting you bring this up. I've been taking a look at the geoclue > position api for the last day and have been trying to clean it up make it > sane and useful. I am trying to add a doxygen layer so that we get some > decent documentation and expand the examples. Here is basically the new > xml files that I am proposing as of now.
Looks great, although it's pretty hard to read: > - <?view=page&name=htmlcompose&ver=1chdyj2lqwlxk#> <method name="*version*" > > > <arg type="*i*" name="*major*" direction="*out*" /> > <arg type="*i*" name="*minor*" direction="*out*" /> > <arg type="*i*" name="*micro*" direction="*out*" /> > </method> Was this by mistake? Can you upload a cleaner version somewhere? Most of your stuff seemed really good, I'll quote only what I'm going to comment on: > We should be thinking 3D. Hostip can return > 0 for altitude and have a large margin of error. GPS can return what they > know. Agreed, except I don't like returning 0 for missing data -- that has bitten me in the ass several times (you can imagine how nice a 3D terrain model looks like when some random points in the model have a missing altitude value, and that's expressed with a zero...). > As for latitude, longitude error. They typically should always be > the same, but I think it makes sense because all our other methods have 3 > dimensions. Ok with me. I'm not sure how we'll translate single error values like "eph" from gpsd to lat_error and lon_error though. > Do you see any good addition to the status enum? I was going to add a > bunch and then I though a human readable string would be better. The only > ones I thought might be useful are. "No Service Available, No Position > Available, Currently acquiring position.", are these useful to a program or > just the user? If it is useful to the program, then I would add, to the > user then piggy back on the string message. I'd like machine readable versions... It makes UI development a lot easier when you can e.g. show a spinner as long as status is "acquiring" and change that to a error sign when it's "not available". The backend error codes I used (backend/geoclue_position_error.h): GEOCLUE_POSITION_ERROR_NOSERVICE, /* Backend cannot connect to needed service */ GEOCLUE_POSITION_ERROR_MALFORMEDDATA, /* Received data, but it is unreadable */ GEOCLUE_POSITION_ERROR_NODATA, /* Used service cannot provide position data at this time*/ GEOCLUE_POSITION_ERROR_NOTSUPPORTED, /* Backend does not implement this method */ Not sure if the second one has any value. > I think now I'm am going to change timestamp. It probably should be > seconds to the epoch instead of the specific NMEA Time. This will give us > date accuracy (except for the rollover in 2038) timestamp is definitely good. At the same time we might want to think about validity/time-to-live: Sometimes even the last valid location would be useful, even if abolutely current info is not available. > I've been thinking now that we should add a "position_hint" input to the API > for use in auto submitting your position to Host IP. There could be some > kind of configuration for privacy in geoclue master. I wonder if this could > be generic for more API. I know you can do assisted GPS. is there a good > way to add this too? I'm undecided on the data submission issue... I'd probably put the submission in a separate program. I fully agree on the privacy config: there should be geoclue-wide position privacy settings that geoclue _and_ applications can use. Although it might not be a top priority just yet, this will be very important when our position data starts to escape to the internet (like with the Gajim XEP-0080-implementation). Speaking of which, we probably should follow and take part in xmpp/XEP work in that area. > I think I am going to change the internals to all positioning calls > defaultly go to geoclue master and it farms out calls to the available > backends and arbitrates based on accuracy or some gconf keys (preferred, > default). Yay! This was what I was hoping I could do during the summer, but frankly there was enough work even without getting that far... I fully support this. It's not trivial though. > But I think it should also store the most recent position from > each backend, that way if none of them are available it can default to the > last timestamp (and maybe prompt the user for manually inputing their > position) This I already touched on while discussing timestamps. I guess the other alternative to master saving position data is that backends have a method last_position(), and/or that position has some kind of time-to-live ? About the manual input: I'm working on that right now for Maemo, I'll post my ideas/mockups to the list soonish. I can already say I don't like the way the current manual backend works. > Oh yeah, and I don't know if Jussi, you have done some of the object > oriented refactor, but I'm going to do some for the positioning api to try > and make it easier to add a new backend. Go ahead, I haven't worked on that. It was just a "bug report". > Ok, so I think that is all I have. Once this gets done, I think we can go > "beta stable" on positioning and working on making our automake, debian and > doxygen very clean so that other program can start using us more. Yes. The interest is building, we should get ready. -jussi
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
