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