W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2009

RE: Early comparison of Nokia/BONDI APIs

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>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2890AF8605@OBEEX01.obe.access-company.com>
Hi Dom,

Thanks for the comparison.

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 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


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

 * 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.


1. Nokia APIs:


Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda


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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC