We could always give it a go as a non-core plugin (incubation?), then once it matures we can graduate it to core.
On Mon, Oct 22, 2012 at 2:39 PM, Andrew Grieve <agri...@chromium.org> wrote: > Haven't tried it yet, but it looks like you can see if various things exist > without having Camera permission on android using: > http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_CAMERA > > If things do require permissions, then I think it would be reasonable to > use a null value when the permission is off. > > > On Mon, Oct 22, 2012 at 5:23 PM, Brian LeRoux <b...@brian.io> wrote: > >> capabilities api is lower level than plugins that would leverage it. >> (there could be MANY camera plugins for example...and there are.) >> >> think of it as a runtime introspection concern. it should be core, and >> not a separate thing, like whitlisting or whatever >> >> >> On Mon, Oct 22, 2012 at 2:03 PM, Filip Maj <f...@adobe.com> wrote: >> > I would take it one step further and have it be the responsibility of the >> > plugin in the first place to track the capability. >> > >> > I don't like a flat `capabilities` object that is decoupled from the >> > plugin in charge of it in the first place. How would this even fit in a >> > fully-pluginable Cordova environment anyways? A "capabilities" object >> that >> > is part of the cordova "core"? Wouldn't this also force all future >> cordova >> > apps, even without any plugins installed, to require all permissions for >> > platform(s)? >> > >> > On 10/22/12 12:44 PM, "Andrew Grieve" <agri...@chromium.org> wrote: >> > >> >>I like device.capabilities or directly on device. >> >> >> >>Maybe a naming convention would be a good idea for the different types of >> >>things? >> >> >> >>Figuring out the properties might take some time. e.g. we may not need a >> >>bool for frontFacingCamera, but instead: >> >> >> >>capabilities.cameras = [ { direction = {'front'/'rear'/'external'}, >> >>'resolution': '1.2MP' }] // an empty array if no cameras >> >>capabilities.frontCamera = ref to the first cameras entry with >> >>direction='front', or null >> >>capabilities.rearCamera = ref to the first cameras entry with >> >>direction='rear', or null >> >> >> >>Other examples: >> >>capabilities.locationSensors = [{type:'gps'},{type:'wifi'}] >> >>capabilities.gps = ref to {type:'gps'} >> >> >> >> >> >>Do we want any information about the current state of sensors? E.g. >> >>bluetooth currently enabled/disabled. My vote would be no, and that this >> >>kind of info should be the responsibility of a bluetooth plugin. >> >> >> >> >> >> >> >> >> >> >> >> >> >>On Mon, Oct 22, 2012 at 2:55 PM, Brian LeRoux <b...@brian.io> wrote: >> >> >> >>> The longer view would seem that we would want to think this through >> >>> more and give a unified API for any kind of device hardware/sensor >> >>> inquiry. I'm a fan of keeping that decoupled from interacting w/ the >> >>> objects of introspection too---this should be a core part of the >> >>> platform. >> >>> >> >>> window.device.capabilities.* bucket feels right >> >>> >> >>> >> >>> On Mon, Oct 22, 2012 at 9:06 AM, Josh Soref <jso...@rim.com> wrote: >> >>> > For his specific requirement "I need to know if there's a camera", >> >>> certainly the camera API could choose not to be available if there's no >> >>> camera, and merely: >> >>> > >> >>> > window.device.camera == false ? >> >>> > >> >>> > or wherever cordova puts the camera. >> >>> > >> >>> > A capabilities API is absolutely overkill for his requirements. >> >>> > >> >>> > (And yes, that W3 RDF monstrosity is too, but that's no reason to >> even >> >>> look at it...) >> >>> > >> >>> > If the requirement is "I want to be able to lazy load the camera >> >>>plugin, >> >>> and only if there's a camera available", that seems to violate the >> >>>plugin >> >>> model, and the response should be "we promise to try to make the camera >> >>> module load/fail quickly if there are no cameras available". >> >>> > >> >>> > --------------------------------------------------------------------- >> >>> > This transmission (including any attachments) may contain >> confidential >> >>> information, privileged material (including material protected by the >> >>> solicitor-client or other applicable privileges), or constitute >> >>>non-public >> >>> information. Any use of this information by anyone other than the >> >>>intended >> >>> recipient is prohibited. If you have received this transmission in >> >>>error, >> >>> please immediately reply to the sender and delete this information from >> >>> your system. Use, dissemination, distribution, or reproduction of this >> >>> transmission by unintended recipients is not authorized and may be >> >>>unlawful. >> >>> >> > >>
