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.
>>
