Marcin Hanclik wrote:
Hi Marcos,
It is out of scope to define how bindings to features occur.
Why? Where is the scope defined?
The scope (and binding way the binding occurs) is defined in the spec
that is behaving as a feature. Take Geolocation: it clearly states that
binding of the geolocation API happens on the Window object. I guess
that means the scope is the scripting environment.
If a feature wants to override the widget object, then that is ok with
me. We should not impose any restrictions on features and how they are
associated/bound/scoped/supplemented etc. to widgets.
And yes, i.e. we should not limit bindings to API only.
Right.
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?
I don't know. What is the real question you are trying to ask?
What if the feature has bigger scope than just a method or property?
That's fine. It could be like Google Frame, for all widgets care (i.e.,
completely take over the runtime and provide its own runtime).
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.
Why? And also, in the case of APIs like geolocation, you just test if
the geolocation methods are there. I don't understand why you would want
anything else? This is getting into the hasFeature() debate again. I
thought we had proved to you that hasFeature is no suitable and
basically borked.
The phrase "a runtime component" does not entail the fact that the "runtime
component" is runnable. API is just an example.
Yes, that is fine. If it was not available at all, then the widget would
not have run. That is the rule.
If its "run" but not available within the scope of the scripting
environment, then the specification defining the feature should just add
a method for testing that it is available. Or authors should just
provide a fall back for whatever feature, just in case.
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].
I think we are splitting hair here.
What if the feature name would be "hardware://keyboard" indicating that a keyboard is
required for the widget or "codec://H.264"?
That would be fine.
The above could be merged into "device://dev/keyboard" and
"device://codec/H.264" respectively.
That would be fine too.
(another BTW: similarly I would treat the network access as a runtime
component, see the WARP discussions).
That would also be fine too.
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.
