W3C home > Mailing lists > Public > public-sysapps@w3.org > August 2013

Re: Toronto F2F agenda

From: Marcos Caceres <w3c@marcosc.com>
Date: Mon, 26 Aug 2013 09:56:05 -0400
To: Kis, Zoltan <zoltan.kis@intel.com>
Cc: Mounir Lamouri <mounir@lamouri.fr>, Wonsuk Lee <wonsuk11.lee@samsung.com>, Marcos Caceres <marcosscaceres@gmail.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <5253F6C05D314F33ABD2BB254F3677EE@marcosc.com>

On Friday, 23 August 2013 at 08:56, Kis, Zoltan wrote:

> Dear Chairs,
> I would like to ask whether would it make sense to discuss some
> generic design options/patterns (met e.g. during Telephony API
> development) in a separate session placed early in the agenda, maybe
> called "best practices", concerning consistent ways to deal with the
> following topics across the API's (both WebIDL and JavaScript):
> - promises + asynchronous issues
> - system messages /wakeup
> - constructors vs factory methods
> - (short) dynamic/volatile object list representation, e.g. with
> sequence, array, object + change notification events
> - using optional method arguments (shorter spec) vs proper (flexible
> and extensible) encapsulation of functionality in objects (aka using
> service identifiers in methods, or explicit service objects, at least
> in Messaging and Telephony, but the pattern could be applied in any
> API dealing with online services). While the optimal choice may vary
> across API's, it would be good to review such design options and
> perhaps establish a recommended order of preference.
> - add further topics.
> This would help offloading generic issues from the Telephony API
> discussion (even after this, there are enough issues left to fill the
> session).

This would be great, but I'm not sure we have enough expertise to be able to address all the design issues raised. The W3C's TAG is currently looking at documenting some of these best practices and it's also why we now send APIs for review to public-script-coord as early as possible (those are the folks that claim to have the best knowledge of JavaScript API design). Experience shows that best practices shift significantly over time, so it's likely we will need to deal with the API designs on a case-by-case basis. Having said that, there are clear idiomatic issues (raised as bugs) in many of the SysApps API that we need to get consensus on. 
Received on Monday, 26 August 2013 13:56:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:14 UTC