You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Brian LeRoux <b...@brian.io> on 2012/10/19 23:25:08 UTC
capabilities api
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/flash/system/Capabilities.html
[4] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/
Re: capabilities api
Posted by Anis KADRI <an...@gmail.com>.
To give you some more inspiration. This is how WAC does it (and I am not
saying it's better than any of your suggestions).
http://specs.wacapps.net/camera/index.html#the-getcameras()-method
getSomething() would return [] if device does not have that "Something"
feature.
I agree that we should have some extended device information (or
capabilities). Native plugins, as far as I know, are lazily loaded on
Android (whenever they're called/used). I don't know about iOS.
Cheers
Anis
On Fri, Oct 19, 2012 at 6:04 PM, Andrew Lunny <al...@gmail.com> wrote:
> +1 flat hierarchy
>
> The use case as I understand it is
>
> * dev has feature in app that uses camera
> * dev includes Camera plugin in their app
> * app gets deployed to lots of devices, including some that may not have
> cameras
>
> Right now (as I understand it) the process is:
>
> * app shows camera UI; user touches it
> * camera API throws error ("I don't have a camera)
> * app code handles that, tells user
>
> Whereas the feature request would enable
>
> * app detects there's no camera; doesn't show camera UI
>
> One thought is that if plugins can be eagerly loaded, selectively, then
> they can register their capabilities right away. Failing that, plugins
> could just have an "initialize" step that modifies the
> window.device.capabilties object - but that could get confusing quickly.
>
> On 19 October 2012 17:52, Shazron <sh...@gmail.com> wrote:
>
> > But that's not true -- if the Camera API is missing, the device does
> > still have a camera for example. Perhaps the dev wants to
> > conditionally load support for their own Camera plugin, yes?
> >
> > The query code would be the same (in iOS) where we detect everything
> > in window.device. Whether it is fast/slow we haven't determined yet
> > since it would delay deviceready.
> >
> > On Fri, Oct 19, 2012 at 5:46 PM, Jesse <pu...@gmail.com> wrote:
> > > I was thinking that if there is no camera API, or no plugin present
> > > then window.device.camera will be null
> > >
> > > window.device.camera.supports("frontcamera"); // boolean
> > >
> > > However, it is easy enough to map the same thing to :
> > >
> > > window.device.capabilities.frontcamera = false;
> > >
> > > My point is, where is the code that queries the capabilities going to
> > live?
> > > I suggest that each plugin be responsible for detecting what it is
> > > capable of, and setting values that developer code can check.
> > > Otherwise we end up with a huge capabilities detection logic in native
> > > that may not even be used.
> > > ie. I haven't even included camera, or capture, but code is still run
> > > to detect, front camera, back camera, resolution, color depth, zoom
> > > capabilities, hdr, ...
> > >
> > >
> > >
> > >
> > > On Fri, Oct 19, 2012 at 5:44 PM, Shazron <sh...@gmail.com> wrote:
> > >> re: the boolean properties -- I was thinking about Modernizr plus
> > >> yepnope http://yepnopejs.com/
> > >>
> > >> Don't know about the other platforms, but Cordova waits for the
> > >> Objective-C side to return with the device properties before calling
> > >> deviceready, so we need to bench it first
> > >>
> > >> On Fri, Oct 19, 2012 at 5:39 PM, Brian LeRoux <b...@brian.io> wrote:
> > >>> plus there could be more than one camera accessing api (and there
> is!)
> > >>>
> > >>> kinda like the flat bool property approach you propose shaz. the
> > >>> calling code would be clean. worried we're going to end up throwing
> > >>> lots of shit on that pile. also not sure what the perf impact would
> be
> > >>> like. (presumably these are blocking calls which kinda sucks.)
> > >>>
> > >>>
> > >>> On Fri, Oct 19, 2012 at 5:29 PM, Shazron <sh...@gmail.com> wrote:
> > >>>> 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 <pu...@gmail.com>
> > 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
> > >>>>>>> Hmm so then standardizing the .capabilities object becomes the
> > hard part?
> > >>>>>>>
> > >>>>>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io>
> 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 <fi...@adobe.com>
> > wrote:
> > >>>>>>>>>> Tack on a .yep boolean onto every API surface?
> > >>>>>>>>>>
> > >>>>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
> > >
> > >
> > >
> > > --
> > > @purplecabbage
> > > risingj.com
> >
>
Re: capabilities api
Posted by Andrew Lunny <al...@gmail.com>.
+1 flat hierarchy
The use case as I understand it is
* dev has feature in app that uses camera
* dev includes Camera plugin in their app
* app gets deployed to lots of devices, including some that may not have
cameras
Right now (as I understand it) the process is:
* app shows camera UI; user touches it
* camera API throws error ("I don't have a camera)
* app code handles that, tells user
Whereas the feature request would enable
* app detects there's no camera; doesn't show camera UI
One thought is that if plugins can be eagerly loaded, selectively, then
they can register their capabilities right away. Failing that, plugins
could just have an "initialize" step that modifies the
window.device.capabilties object - but that could get confusing quickly.
On 19 October 2012 17:52, Shazron <sh...@gmail.com> wrote:
> But that's not true -- if the Camera API is missing, the device does
> still have a camera for example. Perhaps the dev wants to
> conditionally load support for their own Camera plugin, yes?
>
> The query code would be the same (in iOS) where we detect everything
> in window.device. Whether it is fast/slow we haven't determined yet
> since it would delay deviceready.
>
> On Fri, Oct 19, 2012 at 5:46 PM, Jesse <pu...@gmail.com> wrote:
> > I was thinking that if there is no camera API, or no plugin present
> > then window.device.camera will be null
> >
> > window.device.camera.supports("frontcamera"); // boolean
> >
> > However, it is easy enough to map the same thing to :
> >
> > window.device.capabilities.frontcamera = false;
> >
> > My point is, where is the code that queries the capabilities going to
> live?
> > I suggest that each plugin be responsible for detecting what it is
> > capable of, and setting values that developer code can check.
> > Otherwise we end up with a huge capabilities detection logic in native
> > that may not even be used.
> > ie. I haven't even included camera, or capture, but code is still run
> > to detect, front camera, back camera, resolution, color depth, zoom
> > capabilities, hdr, ...
> >
> >
> >
> >
> > On Fri, Oct 19, 2012 at 5:44 PM, Shazron <sh...@gmail.com> wrote:
> >> re: the boolean properties -- I was thinking about Modernizr plus
> >> yepnope http://yepnopejs.com/
> >>
> >> Don't know about the other platforms, but Cordova waits for the
> >> Objective-C side to return with the device properties before calling
> >> deviceready, so we need to bench it first
> >>
> >> On Fri, Oct 19, 2012 at 5:39 PM, Brian LeRoux <b...@brian.io> wrote:
> >>> plus there could be more than one camera accessing api (and there is!)
> >>>
> >>> kinda like the flat bool property approach you propose shaz. the
> >>> calling code would be clean. worried we're going to end up throwing
> >>> lots of shit on that pile. also not sure what the perf impact would be
> >>> like. (presumably these are blocking calls which kinda sucks.)
> >>>
> >>>
> >>> On Fri, Oct 19, 2012 at 5:29 PM, Shazron <sh...@gmail.com> wrote:
> >>>> 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 <pu...@gmail.com>
> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
> >>>>>>> Hmm so then standardizing the .capabilities object becomes the
> hard part?
> >>>>>>>
> >>>>>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com>
> wrote:
> >>>>>>>>>> Tack on a .yep boolean onto every API surface?
> >>>>>>>>>>
> >>>>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
>
Re: capabilities api
Posted by Shazron <sh...@gmail.com>.
But that's not true -- if the Camera API is missing, the device does
still have a camera for example. Perhaps the dev wants to
conditionally load support for their own Camera plugin, yes?
The query code would be the same (in iOS) where we detect everything
in window.device. Whether it is fast/slow we haven't determined yet
since it would delay deviceready.
On Fri, Oct 19, 2012 at 5:46 PM, Jesse <pu...@gmail.com> wrote:
> I was thinking that if there is no camera API, or no plugin present
> then window.device.camera will be null
>
> window.device.camera.supports("frontcamera"); // boolean
>
> However, it is easy enough to map the same thing to :
>
> window.device.capabilities.frontcamera = false;
>
> My point is, where is the code that queries the capabilities going to live?
> I suggest that each plugin be responsible for detecting what it is
> capable of, and setting values that developer code can check.
> Otherwise we end up with a huge capabilities detection logic in native
> that may not even be used.
> ie. I haven't even included camera, or capture, but code is still run
> to detect, front camera, back camera, resolution, color depth, zoom
> capabilities, hdr, ...
>
>
>
>
> On Fri, Oct 19, 2012 at 5:44 PM, Shazron <sh...@gmail.com> wrote:
>> re: the boolean properties -- I was thinking about Modernizr plus
>> yepnope http://yepnopejs.com/
>>
>> Don't know about the other platforms, but Cordova waits for the
>> Objective-C side to return with the device properties before calling
>> deviceready, so we need to bench it first
>>
>> On Fri, Oct 19, 2012 at 5:39 PM, Brian LeRoux <b...@brian.io> wrote:
>>> plus there could be more than one camera accessing api (and there is!)
>>>
>>> kinda like the flat bool property approach you propose shaz. the
>>> calling code would be clean. worried we're going to end up throwing
>>> lots of shit on that pile. also not sure what the perf impact would be
>>> like. (presumably these are blocking calls which kinda sucks.)
>>>
>>>
>>> On Fri, Oct 19, 2012 at 5:29 PM, Shazron <sh...@gmail.com> wrote:
>>>> 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 <pu...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>>>>>>
>>>>>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>>>>>> Tack on a .yep boolean onto every API surface?
>>>>>>>>>>
>>>>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
>
>
>
> --
> @purplecabbage
> risingj.com
Re: capabilities api
Posted by Jesse <pu...@gmail.com>.
I was thinking that if there is no camera API, or no plugin present
then window.device.camera will be null
window.device.camera.supports("frontcamera"); // boolean
However, it is easy enough to map the same thing to :
window.device.capabilities.frontcamera = false;
My point is, where is the code that queries the capabilities going to live?
I suggest that each plugin be responsible for detecting what it is
capable of, and setting values that developer code can check.
Otherwise we end up with a huge capabilities detection logic in native
that may not even be used.
ie. I haven't even included camera, or capture, but code is still run
to detect, front camera, back camera, resolution, color depth, zoom
capabilities, hdr, ...
On Fri, Oct 19, 2012 at 5:44 PM, Shazron <sh...@gmail.com> wrote:
> re: the boolean properties -- I was thinking about Modernizr plus
> yepnope http://yepnopejs.com/
>
> Don't know about the other platforms, but Cordova waits for the
> Objective-C side to return with the device properties before calling
> deviceready, so we need to bench it first
>
> On Fri, Oct 19, 2012 at 5:39 PM, Brian LeRoux <b...@brian.io> wrote:
>> plus there could be more than one camera accessing api (and there is!)
>>
>> kinda like the flat bool property approach you propose shaz. the
>> calling code would be clean. worried we're going to end up throwing
>> lots of shit on that pile. also not sure what the perf impact would be
>> like. (presumably these are blocking calls which kinda sucks.)
>>
>>
>> On Fri, Oct 19, 2012 at 5:29 PM, Shazron <sh...@gmail.com> wrote:
>>> 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 <pu...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>>>>>
>>>>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>>>>> Tack on a .yep boolean onto every API surface?
>>>>>>>>>
>>>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
--
@purplecabbage
risingj.com
Re: capabilities api
Posted by Shazron <sh...@gmail.com>.
re: the boolean properties -- I was thinking about Modernizr plus
yepnope http://yepnopejs.com/
Don't know about the other platforms, but Cordova waits for the
Objective-C side to return with the device properties before calling
deviceready, so we need to bench it first
On Fri, Oct 19, 2012 at 5:39 PM, Brian LeRoux <b...@brian.io> wrote:
> plus there could be more than one camera accessing api (and there is!)
>
> kinda like the flat bool property approach you propose shaz. the
> calling code would be clean. worried we're going to end up throwing
> lots of shit on that pile. also not sure what the perf impact would be
> like. (presumably these are blocking calls which kinda sucks.)
>
>
> On Fri, Oct 19, 2012 at 5:29 PM, Shazron <sh...@gmail.com> wrote:
>> 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 <pu...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>>>>
>>>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>>>> Tack on a .yep boolean onto every API surface?
>>>>>>>>
>>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
Re: capabilities api
Posted by Brian LeRoux <b...@brian.io>.
plus there could be more than one camera accessing api (and there is!)
kinda like the flat bool property approach you propose shaz. the
calling code would be clean. worried we're going to end up throwing
lots of shit on that pile. also not sure what the perf impact would be
like. (presumably these are blocking calls which kinda sucks.)
On Fri, Oct 19, 2012 at 5:29 PM, Shazron <sh...@gmail.com> wrote:
> 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 <pu...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>>>
>>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>>> Tack on a .yep boolean onto every API surface?
>>>>>>>
>>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
Re: capabilities api
Posted by Shazron <sh...@gmail.com>.
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 <pu...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>>
>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>> Tack on a .yep boolean onto every API surface?
>>>>>>
>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
Re: capabilities api
Posted by Shazron <sh...@gmail.com>.
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 <ag...@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 <fi...@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" <ag...@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 <js...@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.
>> >>>
>> >
>>
Re: capabilities api
Posted by Andrew Grieve <ag...@chromium.org>.
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 <fi...@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" <ag...@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 <js...@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.
> >>>
> >
>
Re: capabilities api
Posted by Brian LeRoux <b...@brian.io>.
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 <fi...@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" <ag...@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 <js...@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.
>>>
>
Re: capabilities api
Posted by Anis KADRI <an...@gmail.com>.
It could get populated/updated by the plugins in charge. The purpose is
informational. If a capability is disabled/not present then the
capabilities object will just have that info.
I like the one object approach myself. I would include it as a device
property though. Something like: device.capabilities.*
On Mon, Oct 22, 2012 at 2:03 PM, Filip Maj <fi...@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" <ag...@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 <js...@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.
> >>
>
>
Re: capabilities api
Posted by Filip Maj <fi...@adobe.com>.
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" <ag...@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 <js...@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.
>>
Re: capabilities api
Posted by Andrew Grieve <ag...@chromium.org>.
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 <js...@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.
>
Re: capabilities api
Posted by Brian LeRoux <b...@brian.io>.
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 <js...@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.
RE: capabilities api
Posted by Josh Soref <js...@rim.com>.
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.
Re: capabilities api
Posted by Jesse <pu...@gmail.com>.
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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>
>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>> Tack on a .yep boolean onto every API surface?
>>>>>
>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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
Re: capabilities api
Posted by Brian LeRoux <b...@brian.io>.
http://www.youtube.com/watch?v=Drkh0YLF8rI
On Fri, Oct 19, 2012 at 5:24 PM, Shazron <sh...@gmail.com> wrote:
> I would think all the properties would return a boolean?
>
> So for example, an iPhone 3GS would be:
>
> window.device.capabilities.frontcamera == false
> window.device.capabilities.backcamera == true
> window.device.capabilities.flash == false
> window.device.capabilities.compass == true
> window.device.capabilities.accelerometer == true
>
> etc - flat hierarchy
>
> On Fri, Oct 19, 2012 at 5:16 PM, Brian LeRoux <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>>
>>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>>> Tack on a .yep boolean onto every API surface?
>>>>>>
>>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/
>>>>>>
>>>
Re: capabilities api
Posted by Shazron <sh...@gmail.com>.
I would think all the properties would return a boolean?
So for example, an iPhone 3GS would be:
window.device.capabilities.frontcamera == false
window.device.capabilities.backcamera == true
window.device.capabilities.flash == false
window.device.capabilities.compass == true
window.device.capabilities.accelerometer == true
etc - flat hierarchy
On Fri, Oct 19, 2012 at 5:16 PM, Brian LeRoux <b...@brian.io> 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 <fi...@adobe.com> wrote:
>> Hmm so then standardizing the .capabilities object becomes the hard part?
>>
>> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>>> Tack on a .yep boolean onto every API surface?
>>>>>
>>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/
>>>>>
>>
Re: capabilities api
Posted by Brian LeRoux <b...@brian.io>.
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 <fi...@adobe.com> wrote:
> Hmm so then standardizing the .capabilities object becomes the hard part?
>
> On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>>> Tack on a .yep boolean onto every API surface?
>>>>
>>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/
>>>>
>
Re: capabilities api
Posted by Filip Maj <fi...@adobe.com>.
Hmm so then standardizing the .capabilities object becomes the hard part?
On 10/19/12 4:56 PM, "Shazron" <sh...@gmail.com> 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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>>> Tack on a .yep boolean onto every API surface?
>>>
>>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/
>>>
Re: capabilities api
Posted by Shazron <sh...@gmail.com>.
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 <b...@brian.io> 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 <fi...@adobe.com> wrote:
>> Tack on a .yep boolean onto every API surface?
>>
>> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/flash/s
>>>ystem/Capabilities.html
>>>[4] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/
>>
Re: capabilities api
Posted by Brian LeRoux <b...@brian.io>.
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 <fi...@adobe.com> wrote:
> Tack on a .yep boolean onto every API surface?
>
> On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/flash/s
>>ystem/Capabilities.html
>>[4] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/
>
Re: capabilities api
Posted by Filip Maj <fi...@adobe.com>.
Tack on a .yep boolean onto every API surface?
On 10/19/12 2:25 PM, "Brian LeRoux" <b...@brian.io> 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/flash/s
>ystem/Capabilities.html
>[4] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/