> 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
