It could get populated/updated by the plugins in charge. The purpose is
informational. If a capability is disabled/not present then the
capabilities object will just have that info.
I like the one object approach myself. I would include it as a device
property though. Something like: device.capabilities.*
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.
> >>
>
>
