Even if the spec is stabilised soon, I think we should go ahead with this - if the spec stabilises before release and we implement it in time, then we need never ship it. We can label the permission experimental accordingly, people will know what they're getting into, and what's the point of a master branch if we can't experiment with things like this? I also seriously doubt we're going to have a tonne of apps using web components that are only targeting FirefoxOS (if you use web components and target other browsers, you're almost certainly going to be using a shim of some kind).
This is a major blocker (along with data-store) to us shipping fewer certified apps. We're kind of proving everyone else's preconceptions about the mobile web if we can't actually implement any of the apps we distribute without a special set of features and permissions that we're only allowing to ourselves. I'd love to be able to ship a new homescreen in 2.5 that is only privileged instead of certified. --Chris On Sat, Jul 4, 2015 at 2:26 AM, Tim Guan-tin Chien <[email protected]> wrote: > I would say we shouldn't "add a field" but expose that under a > permission. Make more sense since we already implicitly "grant the > permission" to certified apps. > > That's definitely more code in the layout code though. > > In terms of the policy, I personally think it's fine to grant that > permission to 3rd-party apps -- since apps are (unfortunately) only > distributed on Marketplace right now, we can always take these app > down when they failed to update to the spec'd API in the future. > > > On Sat, Jul 4, 2015 at 6:01 AM, Kevin Grandon <[email protected]> > wrote: > > The only problem I see with this is that the web components > implementation > > is definitely going to change, and will guarantee breakage of most web > > components usage with the current implementation. I would say that we > should > > wait until we have an implementation which will not break in the future > now > > that the spec is more stable. If there is some way to preserve backwards > > compatibility with the current implementation, I'm sure I could be > convinced > > otherwise - but I'm not sure that's something we want to do. > > > > Best, > > Kevin > > > > On Fri, Jul 3, 2015 at 6:36 AM, Christopher Lord <[email protected]> > wrote: > >> > >> We've been using web components in gaia for ages, and it's a > super-useful > >> feature, even in its current state. I've been developing some > components for > >> use in gaia apps, and unfortunately, I've not been able to find any > >> web-components shim that is compatible with them. > >> > >> Guillaume came up with the idea of a custom manifest field to opt-in to > >> our web-components implementation - I think this would be great, what do > >> others think? Is there any really good reason we shouldn't do this? It > seems > >> a bit lame to be withholding a core technology we use in the system apps > >> from 3rd parties. > >> > >> --Chris > >> > >> _______________________________________________ > >> dev-gaia mailing list > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-gaia > >> > > > > > > _______________________________________________ > > dev-gaia mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-gaia > > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
