Early Chromium prototype

[Tyler Close]

I've got a prototype implementation of the Web Introducer for native
Chrome. You can track my progress on this through the bugs:

https://bugs.webkit.org/show_bug.cgi?id=59637

and

http://codereview.chromium.org/6880275/

If you apply those patches to the right version of the Chromium code
base, you'll get an Introducer with most of the basic functionality.
I'm still squaring away some features and there's some supporting code
and unit test and such that still need to be done.

Producing the native implementation forced me to learn some things
about the limitations of Web IDL and the IDL compiler used by WebKit.
Consequently, I needed to make some changes to the Introducer API.
Most of these changes are purely syntax and don't affect the semantics
of the operations. I'll be updating the spec to reflect this new API.

Below is a copy of the new IDL for the Introducer. The conversion from
the prior API should be fairly obvious, but let's discuss any issues.
I also used this opportunity to use less creative names for the main
methods: "introduce()" became "connect()" and "welcome()" became
"accept()", in an analogy to socket APIs.

module introducer {

interface [
Conditional=INTRODUCER
] Introducer {
void install(
in [ConvertUndefinedOrNullToNullString] DOMString icon,
in [ConvertUndefinedOrNullToNullString] DOMString name,
in [ConvertUndefinedOrNullToNullString] DOMString home,
in [Callback, Optional] VoidCallback callback);
void uninstall();
void offer(
in DOMString id,
in [ConvertUndefinedOrNullToNullString] DOMString label,
in DOMStringList supports,
in [ConvertUndefinedOrNullToNullString] DOMString window,
in [ConvertUndefinedOrNullToNullString] DOMString frame);
void rescind(
in DOMString id);
void connect(
in Element anchor,
in DOMStringList wanted,
in [Callback] IntroducerConnectCallback callback);
void accept(
in [ConvertUndefinedOrNullToNullString] DOMString registrant,
in [Callback] IntroducerAcceptCallback callback);

};

interface [
Conditional=INTRODUCER,
Callback
] IntroducerConnectCallback {
boolean handleEvent(
in MessagePort service,
in DOMStringList agreed,
in boolean framed);
};

interface [
Conditional=INTRODUCER,
Callback
] IntroducerAcceptCallback {
boolean handleEvent(
in MessagePort customer,
in DOMString origin,
in DOMStringList wanted);
};

}

--Tyler

[Claes]

Hi Tyler,

Nice that this native protype is in place!

I had a quick look at the IDL and compared it with the current
specification. Assume that the updated specification will clarify but
immediate feedback is:

- Seems as the "install" and "offer" methods replace "register". I am
not sure about the relation between "install" and "offer".
- Don't we need an in-parameter for uninstall() ?

Best regards
Claes

[Tyler Close]

On Fri, Apr 29, 2011 at 12:45 AM, Claes <cgvni...@gmail.com> wrote:
> Hi Tyler,
>
> Nice that this native protype is in place!
>
> I had a quick look at the IDL and compared it with the current
> specification. Assume that the updated specification will clarify but
> immediate feedback is:
>
> - Seems as the "install" and "offer" methods replace "register". I am
> not sure about the relation between  "install" and "offer".

The IDL compiler in WebKit does not support passing structs such as
the old Registration object, so the register call was split in two:
install for the fields describing the Registrant and offer, which is
called once for each Provider to be registered.

> - Don't we need an in-parameter for uninstall() ?

The uninstall() method is equivalent to calling the old register()
method with no arguments, so it deletes the registration and all
registered providers for the calling origin.

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

[Tyler Close]

I've updated the Introducer spec to reflect the native Chrome
implementation. See:

http://web-send.org/introducer/

Other documents on the site still need to be updated.

--Tyler