Re: [vibration] proposed Note text for pattern truncation, ISSUE-149

Agreed it's a bit elaborate. I think the primary idea behind the original
question was whether it is better to vibrate some instead of none. This is
especially appealing because the pattern limits of minimum and maximum
(number of entries, entry duration) are not known and will probably vary by
implementation. Another path we could take is to actually expose the limits
so the developer has no excuse for going out of bounds, but that would
complicate the API.

Thanks,

Michael


On Mon, Oct 14, 2013 at 9:35 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

>
> On Oct 11, 2013, at 6:56 PM, Frederick.Hirsch@nokia.com wrote:
>
> > On yesterday's teleconference we agreed to the following related to
> ISSUE-149:
> >
> > [[
> > RESOLUTION: Adopt proposal as in
> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0012.html,
> adding Note that implementation may break into multiple pieces if list too
> long , potential concern if best effort does not meet application
> expectations
> > ]]
> >
> > I agreed to draft text for a Note related to pattern truncation. I
> propose the following Note (to be associated with step 3 in the adopted
> proposal):
> >
> > [[
> > <div class='note'>
> > If the length of a pattern is greater than max length an implementation
> of this API could consider breaking the request effectively into multiple
> shorter requests internally to achieve the same effect, rather than
> ignoring what follows the max length.
> > There are cases, however, where it is appropriate to ignore the pattern
> exceeding the max length. An example is if the length is so long that it
> would effectively create a denial of service attack on the user.  A web
> application might also make multiple requests if it is known to the
> application that the length is too long for some implementations and a
> possible gap in between patterns is acceptable.
> > </div>
> > ]]
>
> Do implementers (e.g. Michael?) think the Note above would be helpful to
> have in the spec?
>
> On a second pass, this still looks like an implementation detail to me,
> and I'd be a bit hesitant to put this into the spec if it does not lead to
> greater interop.
>
> Also, the note is pretty elaborate in relation to the normative prose
> itself.
>
> That said, I'd like us to not rush this in yet. However, should the group
> think this is helpful, I'll update the spec accordingly.
>
> Thanks,
>
> -Anssi