Re: An alternate approach to enumerating devices

Cullen,

I said I agreed to Travis in this question, and I did that based on two 
assumptions:

* A majority (I guess!) of devices - smartphones, tablets - today have 
two cameras (back and front) and presumably also have platform/OS APIs 
allowing the app (in this case the browser) know which is which of those 
two cameras. I don't think there are platform APIs beyond that, so I 
thought we could wait with defining further direction attributes until 
we get a feeling of where this will be going.

* The most common use of systems with many cameras (left, right, 
speaker, slide, ...) would be in special deployments, like conference 
rooms. For these deployments you'd likely have people mounting cameras, 
adjusting their angles etc., and they would select the right camera for 
the right stream for the web application during the installation 
process. That selection would then be remembered by the web app (by 
using Id's of the sources), and the gain of having left/right 
constraints would be small.

I may be wrong in these assumptions, and would be happy to be corrected.

Stefan

On 2013-04-24 15:58, Cullen Jennings (fluffy) wrote:
>
> I asked a simple question. What harm does adding these 2 more labels
> cause for you. I realize that several people representing vendors
> that do not make or use devices that have left and right cameras
> reponded. However, I do use multi camera systems and it is important
> to me.
>
> So lets talk about complexity - lets say we only do back and front.
> The text in the spec is going to say if you see a value other than
> that you ignore it because that is who we have future extensibility
> for new things. Now if we add left and right to the spec, your code
> code will be *exactly* the same  - it will just ignore the left and
> right as they are not supported. So I do not buy this adds complexity
> in any meaningful way.
>
> Next lets talk about standards. We are trying to come to consensus on
> a set of features that meet the needs to a broad group of people and
> can be widely implemented. So why do you push back on a suggestion
> like this when it costs you nothing? I don't push back on countless
> amount of things that I view as useless or poor designs but that I
> can live with.
>
> Next the narrow view of what is available today leads you to think
> left and right camera are not common. However, they clearly are
> common on higher end systems, and on 3D systems, and that is coming
> down in the market quickly. You should not be at all surprised if
> they become much more common and we are trying to design things that
> work in the future.
>
> So let me very clear, if you are going to object to left and right,
> then I am going to object to front and back and propose we put in a
> more general system that meets the needs of all the users because
> front and back don't meet my needs.
>
> In a more genreal framework, I would love to hear from people about
> the general problem here of are we trying to do something that meets
> the needs of a wide range of users
>
>
>
> On Apr 22, 2013, at 9:24 PM, Travis Leithead
> <travis.leithead@microsoft.com> wrote:
>
>> I don't think that devices with a left and/or right-oriented camera
>> can even come close to the distribution of mobile devices that have
>> front/rear cameras. I'd prefer to stick with the basic front/back
>> and then see if need to augment in a future version of the
>> standard.
>>
>> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
>>
>> On Mar 27, 2013, at 11:28 AM, Martin Thomson
>> <martin.thomson@gmail.com> wrote:
>>
>>> I assume that you want to extend the "facing" enumeration to
>>> encompass new properties:
>>>
>>> "rear": pointed (approximately) from the device to the space
>>> directly away from the device user "front": pointed
>>> (approximately) from the device directly toward the device user
>>> "left" pointed (approximately) from the device to the space to
>>> the device user's left "right" pointed (approximately) from the
>>> device to the space to the device user's right
>>
>> Yes, that sounds good. I think this represents the optimal point on
>> the slope as it represents what we have deployed today in millions
>> of devices. This would solve a bunch of issues for me - does anyone
>> see any harm in using this as the stawman list to move forward
>> with?
>>
>>
>>
>>
>>
>>
>>
>>
>
>

Received on Wednesday, 24 April 2013 14:33:48 UTC