<scribe> ScribeNick: Florian

<aswan> i joined the one from the invitation but am the only one there...

<mikepie> It

<mikepie> It's failing for me too

<mikepie> I'll resend...

<AndersR> hangout problem here

<shwetank> anyone here? Im trying to connect to the google hangout, but its giving me erorrs while also saying im the only one in the call

<John-Galt> shwetank: https://hangouts.google.com/call/kkkwlctkpfanfbcbggl5tn2diye

Joint statment

Florian: Where do we go from the basic draft we have?

mikepie: I can understand from an implementation perspective how these two might overlap
... but I am not sure I understand how it helps us to raise this to the TAG etc.

Florian: To me the idea is to notify the TAG that we're working on an area where it seems that other groups have interest working on as well. We're about to do our own thing, but if a grand unifying solution should be made instead, they should wake up now and kick off something, otherwise, we'll do our thing

AndersR: I have tried to interest the TAG in such things before, but they didn't pay attention. I'm just an individual, but if there is more people interested in the topic, including large corps, maybe they'll pay attention this time.

mikepie: Who was on the web payment side? Eirk?

Florian: Yes, but we haven't talked since TPAC

AndersR: Someone from google as well.

mikepie: I'd be curious to hear about what they think. I don't think what they're doing requires explicit native messaging

Florian: so I suggest we keep moving forward with our specs, and in parallel use that statement to allert the broarder community and see if we get feedback

mikepie: Can we try directly engagine with the web payment folks first, maybe in a call, before spending too much time on a formal statement?

Florian: Sure

ACTION florian to try and arrange a call with web payment people

https://browserext.github.io/native-messaging/

aswan: Mike has done a lot of work, and made an outline for the draft
... mike explained that Edge is planing to take a different route from Mozilla and Chrome on some aspects, so we decided to leave these parts unspecified
... where we are differing is the actual protocol between the browser and the native app.
... the part that will be specified then is permission, the manifest, and the API that the browser exposes to the web app.
... IPC and finding applications would be out of scope.
... that will simplify what the spec needs to cover

Florian: so setting up the environment, launching the app, etc would be non standard, but talking to it would be

aswan: essentially.
... that enables more platform integration and doing things the native way

mikepie: Yes. A way to look at this is that we are standardizing the web part, but the native part remains system specific.

Florian: as we're not trying to recreate flash or NPAPI, and not trying to distribute native code, but to integrate with an environment that's presumably already there. So on a first approach that makes sense to me.

mikepie: (aside: I cleaned up the spec and added some script, now it's nicer).

Florian: I am a bit surprised that ReSpec can't solve these things for you, but if it works now, fine

mikepie: I'll keep digging the respec doc, but for now it works

aswan: we had a recent meeting as a kick off just to established the outline, now we need to fill things in.

Florian: anything to discuss here now?

aswan: first we need to fill in the document, then work through issues

Florian: Ideally let's work on the issues on github, and if something gets stuck we can use this call.

Logo

mikepie: Our tweeter feed still has an egg. This is embarassing.

Florian: yes it is

<John-Galt> https://github.com/mozilla/OpenDesign

kmag2: we have a community design portal, that could be relevant

<aswan> i have another meeting starting, have to drop off...

Florian: I am skeptical of design by comittee

kmag2: it wouldn't be that

Florian: then sure.

shwetank: Can we start with something as a default, and improve on that as we get feedbac? I like 8

Is this the updated version: https://mikepie1.github.io/browserext-1/LogoIdeas.png

<John-Galt> 8/7

Florian: Strall poll: pick your favorite two, ranked

<mikepie> 6,5

Florian: 8, 5

<shwetank> 8/9

<AndersR> 8/9

Florian: looks like an 8 to me. Everybody can live with that?

mikepie: sure.

Florian: Mike, please send me the good quality version, and I'll use it for the twitter account

shwetank: would prefer a while background

mikepie: you would only see the shield then

shwetank: ok

ACTION kmag2 to get feedback from Mozilla

https://browserext.github.io/browserext/

mikepie: I'll walk you through the updates first
... I have registered the URI scheme.

Florian: thanks

mikepie: Also referenced our specifications with SpecRef
... also added the script I mentioned earlier to get nice formatting for WebIDL
... I've synced the issues in the spec and github

Florian: Nice, thanks.

mikepie: Issue 1 and 2 and large todos for myself.
... we talked about trying to be consistent on IDs. I would be ok with not doing that, but if we should do it, doing it now would be good. I'll talk to my team
... Issues in green are marked as resolved. I'll remove them with the next pull request, so I'd like you to confirm that they're all OK.

(not minuting the issue numbers as they are changing)

mikepie: we removed the mention of bookmarks

Florian: can do it later right?

mikepie: Yes, not part of the core. Can be grafted on later.
... Talking about the availability about the APIs, we define it in terms of the default CSP, with a link to it.

(issues 6 7 and 8)

mikepie: issue 10 (github #19). I had text about content scripts and imediate events and delayed events, and I wasn't quite sure what it meant anyway, so I've removed for now
... issue 11, at tpac we had decided to remove the optional permission part of the table. Now that's done.
... Specified that unknonwn manifest keys can be ignored

Florian: do have normative text about the mechanism to require some keys, to deal with forward compat?

kmag: I don't think that's in there yet

mikepie: I'll add an issue for that

Florian: yes, it would be good to have in the spec now that keys can be otherwise ignored

mikepie: issue 13 is about my bit of helper javascript
... Issue 14. Waiting for Andrey

Florian: Please at mention him (and me) in github. Will follow up

mikepie: 15/16: at tpac we agreed on formatting for the webIDL, so I made these changes.
... 18. This was just a work item for me, I filled a section in.
... issue 19 / gh11. At Tpac we agreed about removing the extension object because it was redundant with runtime. So I did that.
... issue 20 / 21. Just work items for me.

kmag: I'll add in some documentation from our code. Chrome documentation is a bit light, so there are details to fill in

mikepie: thanks
... started to do some research about whether our API coverage is sufficient for good support of basic extensions.
... lastError and onInstalled would help a lot of extensions

kmag: not sure about lastError. Not really needed if we're going the promisses

Florian: didn't we say we kept callbacks as a fallback?

kmag: that's what firefox does, but I thought said we would not including that in the browser namespace, and if you want to do callbacks, you'd do it with a polyfil, maybe under the chrome namespace

mikepie: that's what we were discussing, but we hadn't resolved

shwetank: I think I want callback fallbacks, but I'll think about this

<kmag> https://github.com/kmaglione/webextension-polyfill

kmag: the polyfill library I wrote only supports promisses in the browser namespace. we could do it the other way around

<kmag> That should be https://github.com/mozilla/webextension-polyfill

Florian: we need an issue in github to track this debate

mikepie: one last thing. It looks like "capture visible tab" and "onReplaced" would help cover a lot more extensions

kmag: not sure about onReplaced. We have it as a stub, but it is not backed by actual functionality. I don't actually know when chrome actually triggers it.

shwetank: haven't seen people use it

mikepie: so we can skip that one.

next meeting

all: argue back and forth

Florian: So we go with Monday novemeber the 17th, half an hour earlier than today (anchored on US time zones)

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/note/not/
Found ScribeNick: Florian
Inferring Scribes: Florian
Present: Florian mikepie Kris Maglione
Got date from IRC log name: 20 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/20-browserext-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.