- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Fri, 2 Oct 2009 13:34:36 +0200
- To: Marcos Caceres <marcosc@opera.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
Hi Marcos, >>> 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. So let's imagine the following: <feature name="device://dev/keyboard" required="false" /> How do you test that keyboard is actually there then? Do you assume that there will be some keyboard specific function to discover whether the keyboard is there? Then we would need to prepare such a function for each feature. Design like this would actually double the information required for 1 bit test of keyboard availability. If "device://dev/keyboard" and a method like isKeyboardThere() would be required, then I think it is a non-optimal design/architecture. Discovery mechanism in TWI based e.g. on IRI would work for all features, so I think it would be a more generic architecture. >>Why? And also, in the case of APIs like geolocation, you just test if >>the geolocation methods are there. I think there are different opinions about that in general, see e.g. [1]. >>I don't understand why you would want >>anything else? Because not all features are APIs and not all non-API features need API to make the whole stuff work correctly, IRI is enough for identification of features' existence. >>This is getting into the hasFeature() debate again. I >>thought we had proved to you that hasFeature is no suitable and >>basically borked. I understand that hasFeature() has not worked on the Web as it was designed to work, specifically because in this context we talked only about APIs. Also, hasFeature() is still there in the currently discussed W3C drafts. There are valid use cases where the discovery of the available, but optional, features are important, therefore I do not know why we should refrain from standardizing it. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0034.html 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: Marcos Caceres [mailto:marcosc@opera.com] Sent: Friday, October 02, 2009 11:36 AM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [A&E] Last Call comments (2): discovery & localization 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. ________________________________________ 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 Friday, 2 October 2009 11:35:37 UTC