On Thu, 2010-06-24 at 23:56 +0300, Stefan Kost wrote: > Am 24.06.2010 20:44, schrieb Javier Fernandez Garcia-Boente: > Thanks for the patch - just some small patch review: >
Thanks. I'll add thos changes to my git repository. I have to admit that it was a patch not very detailed and overall, too much focused on what the WebKit unit tests was requesting. I think this patch should be implemented in a more general way, more aligned with what GeoClue wants to provide to the users. However, I wanted to start first a brief discussion about what is the best approach to proceed to fulfill the requirements of the WebKitGtk port Geolocation unit tests. First of all, as i already commented before, I think that GeoClue be the first implementation of the Geolocation API of the WebKit project is something very interesting for GeoClue; WebKit is gaining more importance nowadays and probably not too much effort should be invested to, at least, complete the implementation of the unit tests. The best approach in my opinion would be to implement the Position interface on the Manual provider, which is the one best fitting, from the conceptual point of view, with the unit testing purposes. The Localnet provider could be also a good candidate; i've already been told there is already a bug and a patch proposal for implementing the Position iface on the Localnet provider. Another question would be if the SetPosition method, the one used for setting a dummy coordinates, should be exposed by the Position interface. I dont see too many uses of such method, besides unit testing, so i would not go for it. However, this way requires the weird constructor added in the GeocluePosition class, geoclue_position_iface_new. The problem is that the MasterClient should be used to set the dummy location if we want to be aware of the position-changed events. even though we only need them because the Manual provider has the "ProvidesUpdates" flag. So, the goal of implementing all the WebKitGtk Geolocation unit tests would require a deep analysis of the current Geoclue design and perhaps some internal changes, which might be i haven't enough knowledge about to analyze or propose new approaches. I would like to know the opinion of the ones with more experience and knowledge about the Geoclue design and internal structures. Anyway, thanks again for your comments and they will be added to my local repo. Greetings, -- Javi
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
