RE: [A&E] Last Call comments (2): discovery & localization

Hi Marcos,

>>It is out of scope to define how bindings to features occur.
Why? Where is the scope defined?
And yes, i.e. we should not limit bindings to API only.

>>If you want to discover if you
>>have a feature, try to run it.

P&C says:
" A feature is a runtime component (e.g. an Application Programming Interface or video decoder) that is not part of the specified set provided by the Widgets 1.0 family of specifications. The feature element serves as a standardized means to request the binding of an (IRI) identifiable runtime component to a widget for use at runtime. Using a feature element denotes that, at runtime, a widget can attempt to access the feature  identified by the feature element's name attribute."

Therefore it is nowhere specified that you can "run" a feature. E.g. how could you run a video decoder?
What if the feature has bigger scope than just a method or property?
If we want to keep the feature more abstract, we should be able to discover whether the feature was available during instantiation or installation of the widget without prescribing that we must "run" a feature.
The phrase "a runtime component" does not entail the fact that the "runtime component" is runnable. API is just an example.
It is simply a component that is "available at runtime" (the interpretation may be different depending on whether you perceive "runtime" as an adjective or a noun) [1], [2].
What if the feature name would be "hardware://keyboard" indicating that a keyboard is required for the widget or "codec://H.264"?
The above could be merged into "device://dev/keyboard" and "device://codec/H.264" respectively.

(another BTW: similarly I would treat the network access as a runtime component, see the WARP discussions).

Although your example uses unknown skynet scheme, it seems to be equivalent to some API-related scheme, whereas a feature has (should have) more abstract interpretation and be extensible to live 10^n years.

Thanks,
Marcin

[1] http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci212933,00.html

[2] http://en.wikipedia.org/wiki/Run_time_(computing)

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: Monday, September 21, 2009 8:09 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [A&E] Last Call comments (2): discovery & localization

2009/9/15 Marcin Hanclik <Marcin.Hanclik@access-company.com>:
> The below comments refer to:
>
> Widgets 1.0: The widget Interface
>
> Editor's Draft 14 September 2009
>
>
>
> 5.1
>
> Configuration Attributes Table does not contain features/params.
>
> We may assume that when the widget gets installed and loaded, the mandatory (@required=true) features were present/accessible.

right.

> However, the widget does not know whether the optional features (@required=false)  are present/accessible.

It is out of scope to define how bindings to features occur. The
specification of a feature must define it's own binding.

That is, imagine a world where:

<widget ...
 id="skynet:T-800"
>
  <feature uri="skynet:crushPunyHumans"/>
  <feature uri="skynet:heatSeek" required="false"/>
  <content src="T800.skynet" type="application/x-skynet-cyborg" />
</widget>

... in T800.skynet...
//check for optional heatSeek feature..
if(this.heatSeek){
  this.heatSeek.scanForPunyCrushableHumans();
}

Where Skynet's Infrared Sensor specification 1.0 contains WebIDL that
supplements the Terminator object.

[Supplemental, NoInterfaceObject]
interface HeatSeek {
  readonly attribute HeatSeek heatSeek;
};

Terminator implements HeatSeek;

> Therefore, I suggest adding the list of available features to the widget object. E.g. as an array of IRI or by means of a query API (or shall hasFeature() work? Not sure why it was removed from the previous WD) so that the widget could discover the available components/features.

What you are suggesting is redundant. If you want to discover if you
have a feature, try to run it. If you don't have it, and you needed
it, then the widget already failed. If you don't have it, and you
don't need it, then just check for its presence (ala,
if(this.whateverFeature)) .

> 5.1
>
> Localization
>
> Shall it be possible for the widget to programmatically discover the localization path it was loaded from (section 9 of P&C)?

Yes, you can check its URI. If the implementation supports the window
object, then it possible.

> [ I understand the folder-based and element-based localizations are specified in P&C and wonder why it is not possible to programmatically discover the localization that was applied (it could also help with testing IMHO). ]
>

Yes, the widget URI scheme will return you the full path though
conventional (DOM/Window Object) methods. Note that with the model we
use, content can come from multiple locales.

--
Marcos Caceres
http://datadriven.com.au


________________________________________

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, 1 October 2009 16:26:16 UTC