See also: IRC log
Florian: Any other item you would like to add to the agenda?
mikepie: nope
https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda
Florian: This is a wikipage to
prepare for TPAC;
... please add topics you want to discuss, and your name if you
plan to attend.
... It should be publicly writteable
mikepie: Looks editable to me.
mikepie: I will be able to attend
the testing sessions on Monday / Tuesday as an observer.
... John Jansen from MS will there and able to represent
us.
... We'll request that this topic be added when the chairs make
a call for the agenda.
Florian: This hasn't been brought to that group yet, has it?
mikepie: Only as a side comment
maybe.
... I'll check if the link I have is the latest version, and
then add to our own agenda as well.
Florian: So we wait for feedback from that group before there is anything more to discuss here, right?
mikepie: Right.
Florian: I've done a light review. I think it can be merged before my comments are addressed and then we track them individually, but if you want to fix them before, that's great too.
kmag: I'll review and send comments today.
mikepie: I try to follow the
proposal around the web IDL, looking for feedback on that.
... There a huge hole: the callback functions aren't defined
yet.
kmag: Might be a good topic for TPAC.
Florian: kmag, do you want merge-then-comment, or comment-fix-then-merge?
kmag: I'd like to comment first.
mikepie: Do we really need the
extension object?
... Much of the APIs there that aren't yet deprecated in Chrome are
duplicated elsewhere.
... I think getURL is the only thing left.
kmag: I think Chrome is moving to deprecate, but getURL is the big chunk that's left and hard to remove.
mikepie: For now I think we can leave it in, but we'll need to come back to it.
Florian: We can spec AND depreacate, if this isn't the way forward, but is still something UAs need for compat reasons.
kmag: We try not to support
deprecated stuff.
... I don't think we need getBackgroundPage and the like. These
are the kind of things we may come back to, but don't need in
the first spec.
Florian: Do you want to go through the comments I've made in https://github.com/browserext/browserext/pull/4#issuecomment-245791954
mikepie: sure
... Comment 1 about titles: I started with something like what
you suggested, but changed cause it felt long. Happy to change
back.
Florian: Please do, would be easier to understand.
mikepie: Comment 2: I think this is normative, and I'll add details about what happens if you try disallowed things anyway.
kmag: We should define that as a CSP ruleset, rather than prose.
mikepie: I'll look at that.
Florian: Comment 3: you say two things cannot be set at the same time. What happens if you try?
kmag: That's browser specific, we support both at the same time.
mikepie: I think Chrome and Edge
reject the manifest if you have both
... I'll make sure the language is clear
Florian: Since Chrome and Edge differ from Mozilla, does one side plan to align with the other?
kmag:We'd rather not change.
mikepie: I'll put some language around that.
Florian: Yes, please spec it one way, and add an issue about not all browsers doing it that way at the moment.
mikepie: Comment 4: CheckAnyPermissions is defined in MDN, what do we do about that?
kmag: Should be in the IDL spec eventually, link to MDN for now is fine.
Florian: Agreed. Put an inline
issue to remind ourselves to have a normative source
eventually.
... Comments 5 and 6 are about the IDL-explaining examples. I
liked having one, wasn't sure why there was two.
mikepie: The second one got a value pulled from the manifest, and in the permissions, there's an array.
Florian: Can't we just keep the second example, and it covers everything?
mikepie: Can do that.
... I've heard that this kind of example wasn't necessary / w3c
like, so I can remove.
Florian: There are different
styles in writing specs. Some prefer to-the-point specs, with
as little fluff as necessary, other prefer making them more
readable and self explanatory to novices.
... Do as you prefer. I prefer having examples and
explanations.
mikepie: I just noticed I messed
up the section numbering. Will fix.
... In the IDL, I've used optional in several places, but I
don't think that's permitted.
kmag: The IDL way to that is to add a question mark.
mikepie: Will do that
kmag: I haven't been involved with the spec much. Hoped Andrew would be there, but he isn't. Happy to talk about the open issues.
Florian: Issue list: https://github.com/browserext/native-messaging/issues
kmag: I think all these issues belong together, and they seem to pertain mostly to web payments. It is not clear yet to me how they are related to what we're doing.
https://github.com/browserext/native-messaging/issues/1
Florian: It seems to me that what is proposed is a different API for a specific use case, not a generic solution. Maybe the specialized API is better for that use case, but I don't see how it addresses the generic concern.
mikepie: I think it is more a question about mobile.
https://github.com/browserext/native-messaging/issues/2
kmag: This is a proposal to allow
native messagine to web pages, not just extensions.
... Doesn't seem related to extensions, and the security
aspects seem underspecified.
RESOLUTION: Close as out of scope
https://github.com/browserext/native-messaging/issues/3
kmag: This is a follow up to
number 2.
... Not relevant in the context of extensions.
mikepie: I agree. Issue 4 seems to be the same. I don't see how it relates to extensions.
RESOLUTION: and issue 4, out of scope for extensions. Redirect to the WebPlatform WG.
https://github.com/browserext/native-messaging/issues/5
kmag: Not sure this is needed as a special parameter. Such information can be communicated later.
mikepie: Doing it this way constrains the format, later it can be anything.
kmag: This may be about command
line parameters.
... Doesn't seem necessary, you can do that with a message.
mikepie: Initialization can send any data it wants, in any format it wants, so this isn't necessary.
RESOLUTION: Close as wontfix, this can be achieved with existing communication mechanisms
Florian: kmag, when do you think aswan can have a draft for the messaging spec?
kmag: I'll check with him. Will let you know if we cannot have it before TPAC.
Florian: That's the end of the agenda. We're adjourned. See you at TPAC.