- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Thu, 30 Jul 2009 10:34:45 +0200
- To: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis <public-device-apis@w3.org>
Hi Dom, Thanks for the comparison. FYI: BONDI has already identified a few issues in BONDI 1.0 spec, and BONDI 1.1 is to be released soon. It will aim specifically on more detailed clarification of the architecture and tighter coupling of BONDI APIs, Architecture and Security Model. Below are my detailed comments, marked with [MH]. Thanks for your feedback. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanclik@access-company.com -----Original Message----- From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, July 30, 2009 9:57 AM To: public-device-apis Subject: Early comparison of Nokia/BONDI APIs Hi, I spent a little of time comparing the APIs that were proposed by Nokia to the APIs proposed by BONDI [1]. My comparison is at best superficial, doesn't cover all the APIs, and I'm not an expert in API design, so some of my remarks may be irrelevant; but I'm hoping it can serve as a starting point for the technical discussions around concrete APIs. * General Some success callback functions defined in BONDI uses a generic interface (SuccessCallback) - they should use sub-classes to identify and define the expected parameters; for instance, in Messaging, ApplicationLauncher, Gallery, etc; in some of these, I believe the success callback may not expect any parameter at all, but that should be made explicit. [MH] Already addressed. SuccessCallback remains with an Object parameter for bondi.requestFeature() method. All other interfaces will use specialized "successcallbacks", with or without parameters depending on the particular interface design. * Calendar Nokia's interface seems much more complete; e.g. BONDI lacks proper handling of recurrent events, which would prevent proper interaction with real calendar applications; Nokia's seem to match roughly the JSR interfaces. * Camera BONDI's interface more complete - allows for video and much more detailed control of camera settings. [MH] Further adjustments of this interface are planned in BONDI. * Contacts Nokia's address interface more precise - note overlap with Geolocation v2 spec: http://dev.w3.org/geo/api/spec-source-v2.html#address_interface (which has more fields: county, streetNumber, premises, additionalInfo; diff 'postalCode' / 'code' Nokia allows for named groups of contacts BONDI has a search interface (not Nokia) [MH] One of the requirements in BONDI was to keep aligned with W3C Geolocation spec. * Messaging BONDI's definition of account interface? (in getAvailableEmailAccounts - cf lack of specialized callback interfaces) BONDI doesn't read (or alter) messages lists, only allows to send Nokia offers to start message editor; has new messages notifications [MH] It will be addressed in BONDI 1.1. Dom 1. Nokia APIs: http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/0001.html BONDI APIs: http://bondi.omtp.org/1.0/apis/index.html ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Thursday, 30 July 2009 08:35:31 UTC