florian: Everyone had their own
extension mechanisms, and then people started looking to use
Google's one, and then Opera switched to blink and got it
... firefox and MS have things that are very close. This CG was trying to standardise it.
... documentation and code went well, not much standardisation work.
florian: few people participate in meetings.
florian: we have a website, 2 specs,
and they have been not moved much for 6 months.
... Looking for people willing to work on this, because it would be nice to have tests, etc
... We had browsers for a while. Some extension developers would like to participate, but cannot do it all.
John: From Edge, we continue to
be interested. But the person doing stuff here got moved. We
ould like this to move forward.
... what do we want to do next - we focused on common subset essential for large extgension developers.
... To what extent could we get Google to participate more? It was notably lacking in the past but there are a lot of people in here.
scheib: Work on Chrome. Don't think
we have direct contributors to extensions area here, but I am
familiar with them.
... When the project launched to standardise we discussed and made some statements of what we were interested in doing - from Devlin.
... Google are interested in standardising some portions if we can work on a standard that moves forward addressing known problems with the system.
... the platform solved problems we had seen in older systems. But we did it very desktop-focused, learned a lot about how people abuse the system
... trying to promote malware :( The majority of users are moving to mobile, the system is not a good fit for mobile.
... Especially for performance.
... We're interested in forward-looking work suitable for mobile addressing problems we see now.
... Also, some APIs should be very user-agent specific, allowing for substantial variation exposing custom functionality.
... Some things become common so we all do the same and then we can standardise, but not everything.
... This approach has a cost - the extensions developer community has to deal with changing API shapes.
... We are working on that so we will offer new capabilities only to people who move to the new architecture.
... Plugins have been around for ages. They offered serious feature power. But extension integrates with user agent, plugin just makes ahole and lets you do different stuff in there.
... so how de we enable new capabilities out of the box, and get us onto mobile.
florian: There was
interest to make the extension world connect to stuff outside
... Interested in the statement about your goals and concerns - I had heard earlier as more like "we're busy and don't want to be held back from breaking things."
... there is willingness in the community to make breaking change. And agree that we are not looking for 100% compat on everything.
... Think the status quo was not seen as a goal but as a starting point.
twisniewski: Representing Andy McKay - we're interested in getting involved and working together, now we are not so buried in development work.
tom: have an
extension on a couple of stores. aliasing a couple of things
was really easy. Getting it to work was one thing - getting it
in the stores was another = publishing process is a
...Any change requires rebuilding assets, etc. That was a pain, while coding is really simple now.
... understand branding requirements, can we relax it?
John: in the
beginning we focused on APIs, knowing the publication pipelines
would be difficult and different.
... so it sounds like we got that bit done and can talk on how to make publishing better. There are some aspects of the ecosystem that are tightly couple to the user agent, some coupled to the underlying platform.
... don't want to get so bogged down in resolving those differences that we cannot move forward the core API stuff. But we feel that pain too, other developers reflect your comment.
florian: Agree on
priority. Distribution is not just technical, there are
business considerations. If the business side wants to share,
the technical side should support that as far as possible.
... side stores for internal use, as well as public app stores, are important. we want to look at that, but it wasn't / isn't the first priority
John: Edge is
struggling to find performance budget to get a nice platform
for extensions on mobile at the moment, but we are very
interested in the discussion.
... So most of our concern will be on desktop but we welcome work that is more focused on enabling mobile-friendly platform ... I don't hear anything in the discussion that makes me think we are going to run into some intractable conflict if we move forward.
scheib packaging and
publishing - we should be looking at web app manifest.
... Service Workers had a lot of antecedents.
... We should work with web standards for e.g. packaging.
florian: Makes sense to go that way if it's where people want to go.
John Sounds reaonsable.
chaals: There are intertwined histories of app/extensions and web standards
scheib: We may get more traction by framing the discussions to make sure we are bringing things closer into the Web ecosystem, where possible.
twisniewski: We also want to focus on what is relevant, and agree that moving into the Web platform as far as it makes sense is the way to go.
challenge for moving to pure web manifest / Web distribution
model is our concern over security / privacy issues.
... We have chosen to have very constrained distribution model, to help us handle those concerns.
... Also coupled to security issues arising from great power. Moving beyond store model, we would need to address this.
scheib Think we should package the assets, but no problem with allowing for curated store as the primary channel.
John: Makes sense.
twisniewski: Collaboration on security / privacy issues would be really helpful. Everyone keeps their own mechanisms and approaches.
MK: would it be
possible to extend the browser with new protocols?
... we try to extend into WoT - can that be better supported in Web Browsers?
florian: If we can do it outside extensions in Web PLatform, that would be better. Otherwise, where we look at using plugin-type extension might be an approach.
twisniewski: My experience
is that if it fits in the Web itself, we would rather do
... Sooo, "Yes. And No."
... start a discussion, and we will try to figure out what happens. Don't be discouraged if something is not getting traction, iterate.
... We are busy, and forget to be diplomatic sometimes.
florian: What is a good
work mode for people to move forward?
... we had github and some teleconfs. Should we do just github, lots of telecons, something else that a person not here needs to describe?
chaals: No github == death. Weekly telecon is required to make sure people are generally available, but too frequent for this.
florian: Yeah, that's how we ended here.
John: I think
there are clearly needs to talk to people outside this room
first, I think we will need some teleconfs, but we can make a
lot of progress on github and not suffer too much pain on
... I'll look for people who can participate.
florian: I can host teleconf - even not being there if that somehow helps.
chaals: A periodic email can serve a similar forcing function - not as effectively as a teleconf buit without having to run a teleconf.
florian: That seems feasible
twisniewski: We're busy...
been trying to replace our legacy API set with new stuff,
aiming to make it shareable.
... trying to add features that are extensions rather than extending the Web in extensions.
... We have bi-weekly meetings on this, and people are welcome to attend and tell us not to build piles of APIs nobody wants that will lead to fragmentation as others do it differently...