Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 17AD2DB4E for ; Mon, 22 Oct 2012 21:39:53 +0000 (UTC) Received: (qmail 46704 invoked by uid 500); 22 Oct 2012 21:39:52 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 46671 invoked by uid 500); 22 Oct 2012 21:39:52 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 46662 invoked by uid 99); 22 Oct 2012 21:39:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Oct 2012 21:39:52 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FRT_ADOBE2,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates 209.85.219.47 as permitted sender) Received: from [209.85.219.47] (HELO mail-oa0-f47.google.com) (209.85.219.47) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Oct 2012 21:39:48 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so2942264oag.6 for ; Mon, 22 Oct 2012 14:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-system-of-record; bh=/Fw/0WX/t8CQqpOfAJMN1ddsRnn6LIINL+q3vzM9YRc=; b=JSQXvZZVorbZ1mZaIK+R/WSY/QRUuAfN+f44qsblShDqnY8G2dLu65vMK+uUKSgroG +Y/Cnu0KBB/Ht4l7aJPIDFVOJ+wio71ZYB/lHfgIdr7y9rrOD+eHfbfl/6HrCTGf1ctS RSRdlwxr2ewiIKxpXh06QWDM9G9dWPvpBQzD1nRzcknjj1AjUUb5u5a91HeYgOZBPt3Y LuBAV/ZvTC251D3RRIkZc/ExseQ8kcKeGLJ1mvH/dciJvsSutlhE7KIDYgxBYaawFX+J u3F3OWfOg2OBP42oO+0PdkRakrZvMZq2WQ2YW5hmh0LvB5DkLYsWeSsAJZROzmp8vtrT O1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=/Fw/0WX/t8CQqpOfAJMN1ddsRnn6LIINL+q3vzM9YRc=; b=YNfZ/xLWR5NDMR9I9jhztPo86cIQHSRSubNwq6Aq0e5Ps9AI7qKm4gi490/M/FuKq7 yAxSaXNG+za9BDYpQn3rho8amuFOiAEL8se7bpKDibBxxPVJuVf6c3EVhbUT9XpjUQaK neeE4+AHsCq2Qbd8J00UedLfyw9XU2lgdX/9hj5Fb8Cny2toQ2G87dudW/+sfaXxwpva e0DNGadAqe0g2/QZUK9KgYHvE5woGcUE12Uoe6kb2DWhXaNI7Dlilcsd7niOBRpswgRU DnCGb2KUuJ0A7Ig1RH/hb3uHyycwiYqg/sADgD+iqPgt6gajx8kmS6RB/Q6swpXxeksw fxrg== Received: by 10.60.169.20 with SMTP id aa20mr9558648oec.105.1350941967802; Mon, 22 Oct 2012 14:39:27 -0700 (PDT) MIME-Version: 1.0 Sender: agrieve@google.com Received: by 10.182.27.68 with HTTP; Mon, 22 Oct 2012 14:39:07 -0700 (PDT) In-Reply-To: References: From: Andrew Grieve Date: Mon, 22 Oct 2012 17:39:07 -0400 X-Google-Sender-Auth: 8-eMb8Q5tgaEvFqvQIX_h0eATLQ Message-ID: Subject: Re: capabilities api To: callback-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=bcaec54d49a61a5f7004ccacb0c2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlFYJ1YEG0LifyvPHDacb64AyegGY/LSF04pyilCwARRgHOVWCAuCvYMpxM+NU+8JxjcDF1+WjHS/SrOHjrMyfQJQZHWnc87SUeWc8y3IMYXUA+NAvbbnGRGTe6Z4W5JnA/ljRO9FDrN/WF3hZ01J1+EUO13B9n8n3HzBjzvB9VnAq1qS+r49p4H6hvd6R1wKOjsG9msftUUy8MmDhbYsd5uJ5Ykw== X-Virus-Checked: Checked by ClamAV on apache.org --bcaec54d49a61a5f7004ccacb0c2 Content-Type: text/plain; charset=ISO-8859-1 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 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 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" 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 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 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. > >>> > > > --bcaec54d49a61a5f7004ccacb0c2--