- From: Suresh Chitturi <schitturi@rim.com>
- Date: Thu, 13 Jan 2011 18:21:48 -0600
- To: "Anssi Kostiainen" <anssi.kostiainen@nokia.com>
- Cc: <rich.tibbett@gmail.com>, <public-device-apis@w3.org>
Hi Anssi, -----Original Message----- From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] Sent: Wednesday, January 12, 2011 10:44 AM Hi, On 12.1.2011, at 17.34, ext Suresh Chitturi wrote: > The issue I see with this approach is that it has nothing to do with the standard we are defining in terms of the API itself and is only informative to show how scripts can create a vCard and set the href. Am I missing something? First, we should reuse established existing standards (e.g. the data URI scheme). Second, we should make the common use case (i.e. reading) easy and provide enough extension points for the less-common use cases (i.e. writing) to build on top. Suresh>> to me write use cases are equally (or sometimes more) important than read use cases but I understand the need to come out with a simple API first. If the API is too high-level developers are forced in a given direction that they may or may not like (and thus ignore it). Making the common use case simple and less-common use cases possible is the "mid-level" I'd like to aim at. Suresh>> I'd prefer to have a good API that we can offer than such 'mid-level' approaches. As far as implementations, in the past we have see PhoneGap status and other inputs that support such methods, and honestly I don't believe it is too complicated to define an API nor a major deviation such approach will cause to UI paradigms used in the web in either seeking user's permission or throwing a dialog. It's hard to get a high-level API right. If that'd be easy we would not have that many JavaScript libraries out there. Suresh>> The real reason for this in my opinion is the timing or lack of standard APIs which often come out late to the market. -Anssi --------------------------------------------------------------------- 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 Friday, 14 January 2011 00:23:03 UTC