W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 02 Oct 2009 13:44:22 +0200
Message-ID: <4AC5E796.7030907@opera.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>

Marcin Hanclik wrote:
> 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.

I'm sorry Marcin, but I respectfully disagree with your position on this 
matter. I do, however, understand your rationale.

Again, my personal position is that we do nothing in the Widget specs. 
If means of detection are required by some feature, then the feature 
must provide them.

I hand it to the rest of the working group to come up with consensus on 
this issue.

Kind regards,
Received on Friday, 2 October 2009 11:44:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC