- From: Suresh Chitturi <schitturi@rim.com>
- Date: Wed, 6 Jan 2010 12:16:00 -0500
- To: "Robin Berjon" <robin@robineko.com>, <richard.tibbett@orange-ftgroup.com>
- Cc: <public-device-apis@w3.org>
Hi Robin, all, I am in favor of 1). It is distinct, elegant, zero risk for conflict and "device" interface is something we can take ownership of without much involvement from HTML WG. Regards, Suresh -----Original Message----- From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon Sent: Wednesday, January 06, 2010 10:30 AM To: <richard.tibbett@orange-ftgroup.com> Cc: public-device-apis@w3.org Subject: Re: Hanging the APIs off navigator.device Hi, it's time to reheat this issue! On Dec 15, 2009, at 10:58 , <richard.tibbett@orange-ftgroup.com> wrote: > Just wondering whether we should settle on a specific approach to > hanging certain APIs off the navigator.device object. To summarise what is in existing drafts and has been proposed, we currently have these abstract variations: 1. Service object, simple method, inside device navigator.device.dahut.graze() 2. Prefixed method, directly on device navigator.device.dahutGraze() 3. Generic unprefixed method, directly on device navigator.device.graze() 4. Service object, simple method, directly on navigator navigator.dahut.graze() I think we should eliminate option (3) because it doesn't scale (if we produce a Unicorn spec, since unicorns graze too we'll have painted us into a corner). The more I think about (2) the less I like it. It makes for a huge device object that doesn't really make much sense as a whole. So I guess the question is how much we mind polluting navigator :) Personally, I don't mind much because it's not a space in which authors normally put stuff so the risks should be low. The downside is that we don't own navigator (the HTML WG does) but I guess we can ask for their review. So I'm going to go with (4), i.e. Doug's proposal which Max already indicated support for. Any other opinions? One reason I'm asking is because once we get our first API out we'll also have to release the Core Device Interfaces, and they depend directly on this decision (I can make the change really quickly whichever option is chosen). -- Robin Berjon robineko - hired gun, higher standards http://robineko.com/ --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 6 January 2010 17:20:43 UTC