See also: IRC log
<Florian> Scribenick: Florian
<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
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
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
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.
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?