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 5FA6AD8BD for ; Sat, 20 Oct 2012 00:30:15 +0000 (UTC) Received: (qmail 13649 invoked by uid 500); 20 Oct 2012 00:30:15 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 13629 invoked by uid 500); 20 Oct 2012 00:30:15 -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 13621 invoked by uid 99); 20 Oct 2012 00:30:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Oct 2012 00:30:15 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of shazron@gmail.com designates 209.85.220.175 as permitted sender) Received: from [209.85.220.175] (HELO mail-vc0-f175.google.com) (209.85.220.175) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Oct 2012 00:30:09 +0000 Received: by mail-vc0-f175.google.com with SMTP id p1so1126108vcq.6 for ; Fri, 19 Oct 2012 17:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=snUW4QOmEfIImh4EcsmijiFPkoejgBsJpOwTQISiP+U=; b=GAHXrVM7rkgR9q3283t3fQYYfv9Yv3hG9lVvhVIMIoRW2/pygzl8pd5y5qCNYSe/HG SnZDJM296y7yoyIqyau9vey1tv4kKxaMgp1g7nyJiCaavPDrMrWjCq9ep2xc5biBN7gt KiV1gcmpjVNRC07KrNq5FqN9hB5ntibiN7ywvz8kgt3yFkObpJB6VhUMprazNEC2t1yO dzhYB9vLkhLmaT5Qg5AufWIW960hSQBKudONeAfI7EjFyPvbmFq4hyYGFOjjFdqUMJSq L6te+WbTwqFUvG/KY9ZQSrZdeOtDAovLag4LlAWd2upNY24SyTiPpaaqFArzfsOVWM+1 X9aw== Received: by 10.52.74.6 with SMTP id p6mr2969054vdv.124.1350692988101; Fri, 19 Oct 2012 17:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.211.232 with HTTP; Fri, 19 Oct 2012 17:29:07 -0700 (PDT) In-Reply-To: References: From: Shazron Date: Fri, 19 Oct 2012 17:29:07 -0700 Message-ID: Subject: Re: capabilities api To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org So... if the device is capable of something (say front and back camera) and we don't enable the Camera plugin, one can't query for it? This is more of a device thing I think than a Camera API thing. Can't think of a scenario besides diagnostics though... On Fri, Oct 19, 2012 at 5:23 PM, Jesse wrote: > Ask the camera API, not the device! Otherwise we will surely be > screwed with every new capability that ever comes out ... > > window.device.camera.capabilities// returns ... an array? an integer? > > or > > window.device.camera.supports("frontfacingcamera"); // boolean > > window.device.capture.supports("h264recording"); > .... > > Since the Camera is really just a plugin to us, we should just be > defining a way for a plugin to describe it's capabilities on a > particular device. > > My 2 cents, ... back to parental leave ... > > Cheers, > Jesse > > > > On Fri, Oct 19, 2012 at 5:16 PM, Brian LeRoux wrote: >> ya. slippery ground. the orig query, and valid one at that imo, is how >> to find out if we have any camera, or two. >> >> window.device.capabilities.camera // returns ... an array? an integer? >> >> >> >> On Fri, Oct 19, 2012 at 5:06 PM, Filip Maj wrote: >>> Hmm so then standardizing the .capabilities object becomes the hard part? >>> >>> On 10/19/12 4:56 PM, "Shazron" wrote: >>> >>>>We already have the window.device object -- we can tack on a >>>>window.device.capabilities object that could contain the boolean >>>>properties or something. >>>> >>>>On Fri, Oct 19, 2012 at 4:52 PM, Brian LeRoux wrote: >>>>> I dunno, I think this is independent of the current APIs. (More than >>>>> one API we have deals w/ Cameras for example.) Seems like we want more >>>>> nuance than boolean too (consider front && back camera). We are >>>>> definitely talking about hardware/sensors detection. >>>>> >>>>> Not loving the w3c cc/pp spec, that RDF business looks hairy, I think >>>>> we need something more approachable like you describe. >>>>> >>>>> >>>>> >>>>> On Fri, Oct 19, 2012 at 4:23 PM, Filip Maj wrote: >>>>>> Tack on a .yep boolean onto every API surface? >>>>>> >>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" wrote: >>>>>> >>>>>>>Community member Ian has noticed our lack of a capabilities api, and >>>>>>>ignoring the snipe at our foresight, I do agree its a missing piece in >>>>>>>the web platform. [1] >>>>>>> >>>>>>>There is some prior art. >>>>>>> >>>>>>>- Media queries have a couple of interesting APIs (matchMedia [2], >>>>>>>window.devicePixelRatio, and potentially a future >>>>>>>navigator.supportsCSS). >>>>>>>- Flash has a comprehensive capabilities API. [3] >>>>>>>- The W3C has a somewhat unwieldy take on this issue. [4] It should >>>>>>>be noted that a new working group at the w3c called sysapps will be >>>>>>>addressing this. >>>>>>>- Tizen has a System Info API (which I'd link to but cannot). >>>>>>> >>>>>>>Does anyone have any thoughts on how we should structure / develop out >>>>>>>the ability for our users to query the device capbilities? >>>>>>> >>>>>>>[1] https://twitter.com/iandevlin/status/259309546969903104 >>>>>>>[2] https://developer.mozilla.org/en-US/docs/DOM/window.matchMedia >>>>>>>[3] >>>>>>>http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flas >>>>>>>h/s >>>>>>>ystem/Capabilities.html >>>>>>>[4] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/ >>>>>> >>> > > > > -- > @purplecabbage > risingj.com