W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

RE: [widgets] What does it mean to have an unavailable API

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Wed, 3 Jun 2009 12:23:19 +0200
To: "marcosc@opera.com" <marcosc@opera.com>, Jonas Sicking <jonas@sicking.cc>
CC: Scott Wilson <scott.bradley.wilson@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C0A26ED90A1@OBEEX01.obe.access-company.com>
Hi Marcos,

requestFeature() from BONDI 1.0 is an asynchronous API that follows API design pattern:

requestFeature() is described in detail in:

section 4.3.2

"A call to the successCallback Function signifies that the request has been satisfied and that the corresponding JavaScript API is immediately available."

It means basically that you can directly use the requested API if the request to have it was successful.
You do not have to perform any further checks and there is actually a bunch of interfaces that are available, not just a single object.


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: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Tuesday, June 02, 2009 7:50 PM
To: Jonas Sicking
Cc: Marcin Hanclik; Scott Wilson; Henri Sivonen; public-webapps
Subject: Re: [widgets] What does it mean to have an unavailable API

On Tue, Jun 2, 2009 at 7:19 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik
> <Marcin.Hanclik@access-company.com> wrote:
>> Hi Scott,
>> In BONDI we have discussed the (has/request)Feature() for some time.
>> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, section 4.3
>> A few points for further discussion:
>> 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well.
>> 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by <feature>.
>> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details.
> Doesn't the requestFeature() make at least the security benefits of
> <feature> moot? In Another thread Marcos stated that one of the
> benefits of <feature> was that if a widget gets exploited, the
> exploited code couldn't get access to any features that the widget
> hadn't enabled using <feature>. However this does not seem to be true
> if the exploited code could simply call requestFeature() first, and
> then use the feature.

I don't know what the BONDI doc says, but this is certainly not what
should happen (unless something changed since I stopped working with
Bondi on this). The idea with getFeature, IIRC, is that you first
declare a feature, e.g., <feature name="foo:bar">, and then you can
ask for an pointer to it at runtime:

    var foobarator =  Bondi.getFeature("foo:bar");

    var barfoo  = Bondi.getFeature("bar:foo");
    barfoo === underfined; // true

Marcos Caceres


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 Wednesday, 3 June 2009 10:24:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC