breautek commented on PR #298: URL: https://github.com/apache/cordova-plugin-geolocation/pull/298#issuecomment-4833089280
> why do we need this plugin at all? I have tried to access navigator.geolocation on a basic Hello World app without this plugin on both Android and iOS and the API was available and functioning on both. It's probably been very long time this was last evaluated -- so there might not be even a need for this plugin anymore... I do know that the Android's implementation of this plugin is exclusively to handle permissions. It doesn't actually integrate the location APIs itself and instead lets the native web API do the work. Natively, to use the geolocation APIs there are web client hooks for permission requests which I would assume still be required. It might have worked for you without the plugin if your app already had the permissions granted. With that being said, the webview implementation of the API does not give you control over the distanceFilter and other configuration properties that iOS offers -- and whatever what they use might not align with your needs either. > If we do have a plugin, why not leaving the basic W3C-compatible API as default and allowing optional, extended features? This would make the plugin more useful than a copy of the standard navigator.geolocation ? I think that's the decision for a dev mail list buy-in to not only decide if the feature warrants adding in the non-standard feature but in how do we expose non-standard features. I'm not saying this PR doesn't provide any usefulness -- in fact I have this plugin forked for one of my apps as I require a continuous stream of GPS events, so I need iOS to use a distanceFilter of `0`. Therefore I'd personally would benefit from this change. But if we are going to expose non-standard features we might want to ensure we do it in a way where it is completely obvious and that it avoids any potential of namespace clashing that may occur in the future should the W3C spec itself extends the geolocation API. Case in point the [File](https://github.com/apache/cordova-plugin-file/issues/316) plugin is an API that adds a Cordova implementation, includes non-standard features and overwrites the native web File API making it very difficult for people who need to use both the file plugin and native web file api features. And to top it off, changing the cordova api to even use a different name is something that will broadly break things. But anyway that's a decision for the mailing list. The counter argument is the community may want to keep this plugin clean from extensions so that Apache can eventually deprecate and stop maintaining the plugin altogether -- and that would be one less workload that needs to be maintained. Adding in non-standard APIs would basically mean Apache need to maintain the plugin forever. Therefore the community might prefer to have these kind of changes available in a third-party fork rather than within the Apache maintained codebase. > Happy to bring this discussion to the mailing list (which is?). Instructions can be found at https://cordova.apache.org/contact/ Anyone can write to [email protected] but to observe replies, you'll need to write a non-empty email to [[email protected]](mailto:[email protected]) to subscribe to the mailing list, so that the mailing list will forward dev@ emails to you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
