Re: Gamepad scope

Hi All,

It's good to see scoping questions being raised now. I agree with 
Sangwhan's comments and the not in scope items. A few additional 
comments ...

As we have done with the Touch Events v1 and v2 specs, perhaps it will 
make sense for v1 of the Gamepad API to be relatively narrow in scope 
and cover core functionality that is already deployed and to use v2 for 
additional features. [That's a question, not an assertion ;-)]

Re vibration and sensors, indeed related work is already in scope for 
the DAPI WG. We have at least some active members in both WGs (e.g. 
Cathy and Laszlo) and I think Robin and/or Frederick are subscribed to 
this list. As such, it should be relatively easy to collaborate with 
that WG. Additionally, we could set aside some time during our November 
1 TPAC meeting to meet with some members of DAPI (although they don't 
meet that week until Nov 3-4).

Re accelerometer, indeed that is in scope for the Geolocation WG. I 
don't know if we have any cross-WG members (please speak up if you are!) 
but if we have related use cases or requirements I think we should 
definitely talk to that WG (and if they are meeting in TPAC perhaps some 
f2f time would be useful).

-Art

On 10/6/11 8:02 AM, ext Ted Mielczarek wrote:
> On Thu, Oct 6, 2011 at 12:51 AM, Sangwhan Moon<smoon@opera.com>  wrote:
>> On 2011/10/06, at 11:27 AM, Ted Mielczarek wrote:
>>> * Accelerometer support (really neat, but need to get a feel for how
>>> consistent it is across devices)
>> The geolocation group has something similar to this here:
>>
>> http://dev.w3.org/geo/api/spec-source-orientation.html#deviceorientation
>>
>> Could be used as a starting point, but also having two specs doing very similar things
>> will either result in duplicate work and/or fragmentation. Not sure if we want to go down
>> that road.
> We discussed this when it first came up. If we spec this we'll
> definitely find a way to work with that existing spec. We certainly
> don't want to reinvent the wheel, but we also can't entirely defer to
> that spec since the use cases are slightly different. (Single
> accelerometer in a device vs. multiple controllers with
> accelerometers.)
>
>>> * Rumble/vibration support
>> Would be nice to have in a separate scope of gamepad, since force feedback can exist
>> in a non-gamepad context. (i.e. force feedback + touch events for Bejeweled like games,
>> or force feedback + orientation for driving games comes to mind)
>>
>> The catch is probably the fact that it's too minimal to cover in a separate spec (since, most
>> of the implementations I've seen have only a handful of methods in the API) - although it
>> seems like the Device API WG does have a separate Vibration API in their charter.
>>
>> Doesn't look like a lot of effort has been put into this particular subspec, maybe it's better to
>> sync up early and make sure we don't duplicate work.
> Yes, we should definitely sync up there. I have a colleague who's
> prototyping a vibration API in Gecko[1], we've been in contact
> already. I'll see if I can find someone in the Device API WG who's
> interested in vibration support.
>
>>> Things that we will definitely not spec:
>>> * Wiimote pointer motion
>>> * Camera sensors (including Kinect)
>> I'll have to say that the elephant is in the room, when it comes to this and vibration.
>>
>> Probably worth taking a separate discussion about the elephant.
> We had this discussion on a call (last week?). There are patent
> concerns if we don't have a WG member that is involved in producing
> the technology, first of all, and second, it's so different from
> standard game controllers that the spec is unlikely to have much
> overlap, so I think it's fair to keep this separate for now.
>
> -Ted
>
> 1. https://bugzilla.mozilla.org/show_bug.cgi?id=679966
>

Received on Thursday, 6 October 2011 12:25:00 UTC