RE: Event handlers - Pointer Devices

(following up slightly on a DAP tangent, as this relates to "events" as an API feature)

Overall I think "events" are baked into API's in DAP, in many cases, and that you really can't separate them. In the case watching for changes in device properties (which otherwise would be a simple synchronous read of a device property), the event is a basic aspect of the API's nature. So separating this out at the charter would not be helpful IMO.

Instead of starting an (also) potentially unhelpful discussion of charter (given the earlier guidance in this thread), I just wanted to point out that the distinctions between Webapps and DAP are not so clear to me (my problem I guess), and maybe there's something we can do in the future to address that (if we need to).

Otherwise, I recommend that the DAP questions go to that list.

Thanks, 
Bryan Sullivan | AT&T

-----Original Message-----
From: Charles Pritchard [mailto:chuck@jumis.com] 
Sent: Thursday, March 04, 2010 10:31 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Doug Schepers; public-webapps@w3.org
Subject: Re: Event handlers - Pointer Devices

`
 > On the main (or more useful) point perhaps, I think the distinction
 > between a device's internal features, its peripherals as attached
 > features, and more abstracted (even remote) resources is still very 
blurry
 > between Webapps and DAP.
...
 > Bryan Sullivan | AT&T

Perhaps the "System Information and Events API" section of the DAP 
charter should be two separate items. It seems to me that Events are the 
cause of the confusion here; and they are complex. The charter summary 
doesn't mention that most of the protocol APIs could trigger events.

For instance:

Many Cameras will be supporting simple image recognition of 2d barcodes; 
onbarcode() would, for instance, be an event. such an event would likely 
be in the DAP charter, not in the WebApps charter (am I wrong?). 
Additional events would encompass the current device APIs ( 
oncamerastart, ontaskadded, onnetworkunreachable, etc ).

The DAP really seems quite restricted to PIMs, which is surprising. 
Where do measurement accessories such as accelerometer, thermometer, 
compass, and other measurement services fit?

 > From: Doug Schepers
...
 > DAP is not focused on user-input devices, more on things like cameras,
 > calendars, etc. available on the local device.
 >
 > I am concerned that it may not be fruitful, and may be
 > counterproductive, for us to start speculating on this list about IPR.
 > Let's keep the discussion on technical matters, please.
...
 > However, use cases and requirements would be appropriate to discuss, and
 > this should help frame a successful outcome for this spec.
...
 > [1] http://www.w3.org/2009/05/DeviceAPICharter


Well, I'd like to speculate a little: touch is not patented but "gesture 
recognition" is. Working within that framework gives us a firm scope: 
"onpressurechange" is a touch event, "onPsychicRaysOfIntent" is 
something that can be left up to a mechanism detailed by the Device API 
group. Gestures may well belong to a persons personal device profile.

I've seen requests for "ondeviceshake", "onpinch", but I fear that 
implementations might run afoul of existing IP. There are also better 
names, that target their typical functionality: "onpinch" is often used 
to trigger a zoom command; "onzoom" (or a borrowing from SVG), would 
allow for the same functionality, without suggesting a gesture 
recognition system.

I realize that it'd be far easier to write some applications if these 
high level APIs were part of every implementation, but I think they are 
too risky. What is a "pinch", what threshold should a "shake" have? 
These are details to be left to individual implementations. Let's 
sidestep the issue early.


-Charles

Received on Saturday, 6 March 2010 22:12:06 UTC