See also: IRC log
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? Erik?
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, even if there may be such a thing as an underlying mechanism.
Florian: so I suggest we keep moving forward with our specs, and in parallel use that statement to alert the broader community and see if we get feedback.
mikepie: Can we try directly engage with the web payment folks first, maybe in a call, before spending too much time on a formal statement?
Florian: Sure.
<scribe> [NEW] ACTION: Florian to try and arrange a call with web payment people [recorded in https://github.com/browserext/native-messaging/issues/6#issuecomment-255313904]
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 permissions, 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, right?
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: 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.
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.
mikepie: Our twitter feed still has an egg. This is embarassing.
Florian: Yes it is.
kmag: We have a community design portal, that could be relevant.
<kmag> https://github.com/mozilla/OpenDesign
Florian: I am skeptical of design by committee.
kmag: It wouldn’t be that.
Florian: Then sure.
shwetank: Can we start with
something as a default, and improve on that as we get feedback?
... I like 8.
Florian: Is this the updated version: https://mikepie1.github.io/browserext-1/LogoIdeas.png
mikepie: Yes.
Florian: Strall poll: pick your favorite two, ranked.
<kmag> 8, 7
<mikepie> 6, 5
<Florian:> 8, 5
<shwetank> 8, 9
<AndersR> 8, 9
Florian: It 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: On Twitter you would only see the shield then, not the rounded corners.
shwetank: Ok.
<scribe> ACTION: kmag to get feedback on the logo from Mozilla [recorded in https://github.com/browserext/browserext.github.io/issues/12#issuecomment-255314648]
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.
mikepie: We removed the mention of bookmarks.
Florian: Can do it later right?
mikepie: Yes, they are just not not part of the
core. Can be grafted on later.
... The availability of APIs is now we defined
in terms of the default CSP, with a link to it.
This is issues 6, 7, and 8.
mikepie: Issue 10 (github #19): I
had text about content scripts and immediate 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.
... I specified that unknown manifest keys can be ignored.
Florian: Do have normative text about the mechanism to require some keys, to deal with forward compatibility?
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 unknown keys can be otherwise ignored.
mikepie: Issue 13 is about my bit
of helper javascript.
... Issue 14. Waiting for Andrey
Florian: Please @-mention him (and me) in github. Will follow up.
mikepie: Issues 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: These are just work items for me.
kmag: I’ll add in some documentation from our code. Chrome’s documentation is a bit light, so there are details to fill in
mikepie: Thanks.
... I have started to do some research about whether our API coverage
is sufficient for good support of basic extensions.
... Adding lastError and onInstalled would help,
as they are used by a lot of extensions.
kmag: Not sure about lastError. Not really needed if we’re going the promises.
Florian: Didn’t we say we kept callbacks as a fall-back?
kmag: That’s what Firefox does, but I thought said we would not including that in the browser name space, and if you want to do callbacks, you’d do it with a polyfil, maybe under the chrome name space
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: The polyfill library I wrote only supports promises in the browser namespace. We could do it the other way around
<kmag> https://github.com/mozilla/webextension-polyfill
Florian: We need an issue in github to track this debate. I'll open it.
This was later registered as issue 38.
mikepie: One last thing. It looks like "capture visible tab" and "onReplaced" would help cover a lot more extensions
kmag: I am 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, the documentation is unclear.
shwetank: I haven’t seen people use it.
mikepie: So we can skip that one.
all: [argue back and forth]
Florian: So we go with Monday November the 7th, half an hour earlier than today (anchored on US time zones).
