See also: IRC log
<scribe> Scribenick: Florian
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
... should be publicly writteable
mikepie: looks editable to me
mikepie: I will be able to attend
the testing sessions on Monday / Tuesday
... 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 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 that aren't yet deprecated in Chrome are
duplicated
... 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
mikepie: comment 2, I think this is normative, and add details about what happens if you try 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 then?
kmag: that's browser specific, we support both
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?
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 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
... comment 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
https://github.com/browserext/native-messaging/issues/1
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.
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
RESOLUTION: Close issue 1 as wontfix, because this does not seem to address the generic solution, only a specialized use case.
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: agree. issue 4 seems to be the same. I don't see how it relates to extensions
RESOLUTION: close 3 and 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 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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/mikepie/kmag/ Found ScribeNick: Florian Inferring Scribes: Florian Present: Florian mikepie kmag Agenda: https://lists.w3.org/Archives/Public/public-browserext/2016Sep/0000.html Got date from IRC log name: 09 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/09-browserext-minutes.html People with action items:[End of scribe.perl diagnostic output]