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
the browser.
... 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
bottleneck.
...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.
John Big
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
that.
... 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
teleconfs.
... 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...