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

RE: Callback naming

From: <richard.tibbett@orange-ftgroup.com>
Date: Wed, 2 Dec 2009 12:50:53 +0100
Message-ID: <355A518BC0575547B2A3D6773AAF8EEF6CABB4@ftrdmel1>
To: <Ilkka.Oksanen@nokia.com>, <robin@berjon.com>
Cc: <public-device-apis@w3.org>
On 2nd Dec 2009 at 11:45, Ilkka Oksanen wrote:
> 
> ext Robin Berjon wrote:
> > E.g.:
> > 
> > PendingOperation captureDahut (in CaptureCallback 
> successCallback, in 
> > optional ErrorCallback errorCallback);
> > 
> > replaced by
> > 
> > PendingOp captureDahut (in CaptureCB successCB, in optional ErrorCB 
> > errorCB);
> > 
> 
> I think this is a good idea. These names will propably appear 
> in every API so it shouldn't be a big burden for the reader 
> to figure them out once (if not evident immediately).
> 
> There is related issue conserning SuccessCallback, 
> ErrorCallback and PendingOperation interfaces. In camera API 
> those interfaces are copied from Richard's Contact API draft. 
> Would it be possible to create common parts specification or 
> something similar for them to get rid of copy paste WebIDL?
> 

In the Contacts API it's a generic SuccessCallback (rather than a
Capture-specific callback) with an object parameter passed through the
onSuccess. In the prose for async methods it describes the format of the
resulting object to onSuccess (e.g. Contact, sequence<ContactResult>,
etc).

If we have a general purpose success and error callback this could be
abstracted to e.g. the Device API [1] and referenced from multiple API
specs accordingly.

Additionally, it could be useful to define some general purpose error
codes centrally somewhere (e.g. invalid argument, permission denied,
etc) and if API specific SuccessCallbacks are required, they can extend
this generic SuccessCallback object (and therefore throw generic and API
specific error codes).

WDYT?

Richard

[1] http://dev.w3.org/2009/dap/device/
Received on Wednesday, 2 December 2009 11:51:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT