incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: capabilities api
Date Mon, 22 Oct 2012 21:43:07 GMT
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 <agrieve@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 <fil@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" <agrieve@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 <jsoref@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.
>> >>>
>> >
>>

Mime
View raw message