Browser Extension CG ad-hoc teleconf — 09 Jun 2016

See also: IRC log

Attendees

Present
Andrey Rybka (andrey-r), Kris Maglione (kmag), Mike Pietraszak (mikepie), Florian Rivoal (Florian)
Regrets
Chair
Florian
Scribe
Florian

Contents


<Florian> Scribenick: Florian

WebIDL conventions

<kmag> https://gist.github.com/97fa5b3cf4599df92ee5066bde47c162

kmag: This link is what I plan to send
... there's basicaly to options:
... one use the CheckAnyPermissions attribute, and one that breaks it down and specifies it in words

<andrey-r> The IDL looks good

kmag: I can walk you through this

mikepie: Please do

kmag: There's a top level interface call ExtensionGlobal
... it has one property, "browser"
... [... describes the content of the mail pasted above ...]

mikepie: I like this model a lot
... it is a clean way to extend window.
... I think it would help if you could expand a bit with examples, to make it easier to understand.

<andrey-r> I agree a little more details would help for anyone on mailing list

mikepie: It can work for dynamic capabilities, added during execution

kmag: That's the way it is done in webapps for the navigator property, saying this must only be exposed in certain contexts.

andrey-r: More details would be good, or people on the mailing list will have a hard time understanding.
... but I like the proposal.

Florian: Where will you send it? both lists?

kmag: I was thinking of the WebIDL mailing list, but I can CC the browserext CG.

<andrey-r> Both list would be good

mikepie: Any thoughts about the events object?

kmag: Would have to give a different name, "tabs" is a terrible name.
... Maybe call it broadcaster or dispatcher or something?

mikepie: If we can move forward with this, I can use it to write up the draft, but there might be some push back, so don't want to rush into using it before we got feedback.

kmag: The only push back could be about using attributes that aren't part of the spec

Top level object name and protocol name

mikepie: I can go with "browser" or "navigator.extension", and prefer "browser", but Opera was preferring the other one.

<andrey-r> I am ok with both

kmag: for the protocol, browser-extensions:// feels too long

<mikepie> How about browser-ext:// ?

<andrey-r> browser-ext:// - Yes

Florian: is browser:// too short for the protocol name?

mikepie: Microsoft people expressed concern about extension:// for being to short / generic.

Florian: browserext:// ?

kmag: Happy eitherway

mikepie: I think browserext:// is good

<andrey-r> agree

Florian: and just browser for the object?

<mikepie> And browser.* for object

Florian: Opera proposed "nex", do we want to to follow that?

mikepie: it does make sense, but I prefer what we just said

kmag: I'd be ok for the top level object, not the protocol

Florian: Seem there's no objection either way, and most people prefering browser & browserext://. Should we resolve on that?

mikepie: Want to loop in Shwetank

Florian: Sure. Resolutions during meeting are provisional anway.

RESOLUTION: use "browser" as the top level object, and browserext:// as the protocol name

Florian: Do we need to register that protocol?

mikepie: I can do that

<scribe> ACTION: mikepie to register browserext:// [recorded in https://github.com/browserext/browserext/issues/3

How to identify functions/properties/events under the objects we've identified

mikepie: How do we do that? Should I prepare something for the next meeting?

Florian: Set it up as a github issue, and we discuss there, and take it by phone once it's settled down somewhat?

mikepie: Sounds good.

Florian: Once we have that and the IDL, we can make a spec that looks like one

mikepie: Yes

TPAC

Florian: What do we want to do there?

andrey-r: Meet :)

Florian: I've requested a time slot, on Thursday IIRC.

mikepie: First time for CGs to meet at TPAC right?

Florian: Yes

mikepie: Should we try and have a more complete spec to review?

andrey-r: Yes, hard to be productive otherwise.

mikepie: Should native messaging be together?

<andrey-r> Native messaging is very important topic

Florian: We can only book for the CG, not per topic, so it will have to be together anyway.

andrey-r: Is this going to be madness again, with stickers on the board?

<andrey-r> Sorry

Florian: Madness is the Wednesday "unconference". CG meetings are different, we should get a sane time slot.
... I'll follow up

<scribe> ACTION: florian to check if we got the time slot requested [recorded in https://github.com/browserext/browserext.github.io/issues/8

<andrey-r> I was saying that I would prefer to meet as early as possible, but if thursday is best for most that's fine

Florian: Houdini shows that you can have productive meetings for high level discussions, but in our case having concrete things to discuss would indeed be better, so let's try to have a draft spec.

next meeting

Florian: It would be good to have topics ahead of time, please file github issues or ML threads.

mikepie: When do we meet next

andrey-r: Anytime!

Florian: Not next week, but anytime is generally OK.

mikepie: June 29, same time?

RESOLUTION: next meeting June 29, same time

Summary of Action Items

[NEW] ACTION: florian to check if we got the time slot requested [recorded in http://www.w3.org/2016/06/09-browserext-minutes.html#action02]
[NEW] ACTION: mikepie to register browserext:// [recorded in http://www.w3.org/2016/06/09-browserext-minutes.html#action01]
 

Summary of Resolutions

  1. use "browser" as the top level object, and browserext:// as the protocol name
  2. next meeting June 29, same time