Re: Distinguishing input from multiple users

Thanks Jacob.  

I totally agree that this should not be specific to pointer events, but handled at
more generic level. We should probably move the discussion to where UIEvent
is being done rather than here.

One concern is the additional complexity required to implement methods to iterate
through available devices and fire events when a new input device is (dis)connected
for the applications to detect. (and the potential security issues on top of that)

--  
Sangwhan Moon


On Wednesday, March 27, 2013 at 7:08 AM, Jacob Rossi wrote:

>  
> (Using this thread to follow up on my Action 30 from today’s call)
>  
>  
>  
>  
> We discussed this issue on today’s call. There were several folks interested in this scenario. We agreed it wasn’t necessary for PE V1 (which you also agreed below).  
>  
>  
> http://www.w3.org/2013/03/26-pointerevents-minutes.html#item05  
>  
>  
>  
>  
> Additionally, one point discussed (for which there was additional support from Olli Pettay and Rick Byers) is that this likely isn’t a problem unique to Pointer Events. For example, there may be multiple keyboards and you wish to differentiate keyboard events by user. Our recommendation is that this instead be considered for UIEvent and not PointerEvent. The current UIEvents spec being produced by the Web Apps group is probably the right place to propose that.
>  
>  
>  
>  
> One concern we should be careful of is to ensure that this deviceId cannot be used to track users across pages. So while the property can differentiate between multiple users of the same application, a given user’s ID should not persist across page navigations. Perhaps to be clearer on that behavior, a name other than “ID” is appropriate. For example, maybe “deviceIndex”.
>  
>  
>  
>  
> I’ve added www-dom to this thread for their consideration.
>  
>  
>  
>  
> -Jacob
>  
>  
>  
>  
> From: Rick Byers [mailto:rbyers@google.com]  
> Sent: Tuesday, March 26, 2013 1:50 PM
> To: Sangwhan Moon
> Cc: public-pointer-events@w3.org (mailto:public-pointer-events@w3.org)
> Subject: Re: Distinguishing input from multiple users
>  
>  
>  
>  
> Thanks Sangwhan.  
>  
>  
> I do think we should do something here, probably combined with enumeration/query APIs (eg. how many touchscreens are there, and how many contacts do each support). It's not clear to me how we'll want to do this in full - eg. a deviceId on the PointerEvent and then additional APIs that operate on device IDs, or an API for looking up the device ID for a pointer ID. So my preference would be to defer to v2, but I don't have strong feelings about it.
>  
>  
>  
>  
>  
>  
> For the WiiRemote scenario, would you expect it would use a custom pointerType, and would each 'device' have exactly one pointer? If so, then it seems like an app would need to know that for your pointerType, each pointer is a distinct user (in contrast to touch for example), and having deviceId wouldn't add much, would it? Multi-user multi-pointer input would definitely be a problem though. Or maybe the problem is that you'd want sites to work without knowing about Wii remotes in particular - if so I'm not sure how that would work.
>  
>  
>  
>  
>  
>  
> Rick
>  
>  
>  
>  
>  
>  
>  
>  
>  
> On Tue, Mar 26, 2013 at 9:03 AM, Sangwhan Moon <sangwhan@iki.fi (mailto:sangwhan@iki.fi)> wrote:
>  
> >  
> > Just to clarify - sorry for not being explicit, this is not a LC comment - nor do I think this should be a v1 showstopper. The added complexity just to get the device ID right on all platforms is probably not worth the hassle to be forced into v1.
> >  
> > The specific use case I had in mind was for HTML games on a console (or PC, TV) - as I've seen a [1] workaround implementation possibly due to the very reason that there wasn't a standard that could be readily used.
> >  
> > (Although as with all software "let's do it later" also tends end up being "let's not do it ever", but let's imagine that won't happen)
> >  
> > The [2] Gamepad API has this concept - although it's a bit more complex - but it shares the idea.
> >  
> > --
> > Sangwhan Moon
> >  
> > [1] http://my.opera.com/Vital/blog/the-wii-remote-api
> > [2] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html
> >  
> >  
> >  
> >  
> > On Tuesday, March 26, 2013 at 11:55 PM, Rick Byers wrote:
> >  
> > > Sangwhan, can you elaborate a bit on the scenario you see this being useful in? Adding a deviceId to the event (or some other mechanism to correlate pointers to devices and get information about those devices) seems like it could be handy, but I'm wondering if this is something we'd really want to try to get into v1.
> > >  
> > > No existing input API has this, right? Are there examples of real-world sites that are hurting as a result?
> > >  
> > > Thanks,
> > > Rick
> >  
> >  
> >  
> >  
> > > On Mon, Mar 25, 2013 at 7:29 AM, Scott González <scott.gonzalez@gmail.com (mailto:scott.gonzalez@gmail.com) (mailto:scott.gonzalez@gmail.com)> wrote:
> > > > I like the idea of having a device id associated with each event. I've also heard requests to be able to listen for when a device is connected/disconnected.
> > >  
> >  
> >  
> >  
> >  
> > > > On Sun, Mar 24, 2013 at 1:54 AM, Sangwhan Moon <smoon@opera.com (mailto:smoon@opera.com) (mailto:smoon@opera.com)> wrote:
> > > > > In the specification as of today, there is no reliable way to detect/associate
> > > > > input from multiple users - as PointerEvent.pointerId is the closest thing that
> > > > > can be used to detect such a thing, which sadly doesn't guarantee a reliable
> > > > > pointerId to user mapping.
> > > > >  
> > > > > I see two approaches for resolving this:
> > > > >  
> > > > > 1) Re-define PointerEvent.pointerId in a way that:
> > > > > - How indices are generated and reserved for non-mice is normative, so it
> > > > > can heuristically map to a specific input device.
> > > > > - Indices are not recyclable.
> > > > >  
> > > > > (and possibly add the concept of "available pointers", or redefine "active pointers")
> > > > >  
> > > > > 2) Add a new deviceId member in the PointerEvent interface.
> > > > >  
> > > > > (and possibly add methods to enumerate available devices)
> > > > >  
> > > > > I'm not sure which would be the best way to handle this, although I am a bit
> > > > > skeptical about the first idea as detecting the device will possibly leave corner
> > > > > cases where the heuristics may fail.
> > > > >  
> > > > > --
> > > > > Sangwhan Moon, Opera Software ASA
> > > >  
> > >  
> >  
>  
>  
>  
>

Received on Saturday, 30 March 2013 06:19:27 UTC