There hasn't been any major push-back on this, so I've gone ahead and implemented it (with a permission, as suggested by Tim). We can resume discussion on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1181555
--Chris On Mon, Jul 6, 2015 at 10:38 AM, Christopher Lord <[email protected]> wrote: > 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
