Re: Discovery API proposals: call for comments

Josh,

I'm not interested in a vendor specific feature. I want a common open
interface that enables television technologies in a standard way that
anyone can use (and is likely to be implemented by commercial browser
vendors) - hence our involvement in W3C.

As for our implementation, we will provide it to the DAP community
shortly. We're in the process of making the code a little more "pretty"
before we release it. I will explain it in more detail when we publish it,
but the way it works is as follows:

It downloads a HTML/CSS/JS web page and a Java Applet from an ordinary web
server. There is NO other code or supporting server or special gateway or
anything. The Java Applet asks for permission to run (since it's not
currently registered to a trusted signing authority - you'll have to trust
me :) ). The JS code calls the JavaApplet API to initiate discovery and
gets callbacks when services are discovered. The user is explicitly asked
permission to authorize any service discovered. Once authorized,
communication with the authorized services can commence. In our case we
implemented a temporary custom XHR (with cross-origination) that complies
with the W3C proposed update to XHR.

I'll explain more later, but the key take-away is that we use our Java
Applet to implement the API we are proposing that overcomes the
limitations of current browsers. We don't know a way to do it in
JavaScript.

Thanks,
-Clarke

On 10/12/11 2:49 PM, "Josh Soref" <jsoref@rim.com> wrote:

>You're sort of saying that "a hypothetical unimplemented api that we need
>can't be implemented by what we have today", that isn't surprising.
>
>I think that using CORS one could get significantly closer, although not
>all the way there unless someone creates a local device/bluetooth gateway.
>
>And someone could implement a java, or native, or whatever app that also
>talks to that remote server and thus enables integration. -- my
>understanding is that you've in fact done this.
>
>Otoh, For a prototype, it would work for testing.
>
>An api is about exposing conceptual features to an application. If the
>features I expose to you don't match your expectation, but they behave
>according to the api, then I, as the user, expect you, my friendly app
>vendor, to use them, no questions asked.
>
>I am not interested in vendor lock in. If you or someone else want a
>proprietary lock in api, then you don't need w3 for it.
>---------------------------------------------------------------------
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.

Received on Wednesday, 12 October 2011 21:54:30 UTC