I think basically we gave up on appcache, it wasnt fast enough and is buggy and service workers are not ready yet
On 5 December 2015 at 10:41, Michiel de Jong <[email protected]> wrote: > Great, I'll make sure to attend that session! :) > > Btw, do you know why the Calculator app is packaged? I unzipped it and > pushed it to https://gaia-calculator.5apps.com/ and it seems to work > identically, and it even sort of works in my desktop browser. (I also tried > with the Clock app, but that relies on mozSettings and some other things). > > Maybe we can use the Calculator app as a super-simple first test case to > make it entirely offline-first and publish it hosted. > > > Cheers, > Michiel. > > > On Fri, Dec 4, 2015 at 4:42 PM, Paul Theriault <[email protected]> > wrote: > >> (was "Re: How to differentiate ourselves from everyone else”) >> >> Splitting this off because I think its important and I want to talk about >> this. We’ve long talked about moving to a more ‘webby’ security model. My >> team has been working to make our package apps more web like, but I >> consistently hear that developers want pure web apps (no packages, no >> signing etc). This won’t be possible for ALL gaia apps - the permissions >> are simply to complex to expose to the web’s untrusted security model. But >> I think its possible if we start talking about splitting gaia apps into >> some hosted and some packaged. >> >> >> > This is something I would really like to do with the new Music NGA app. >> A true “web app” is something that should be able to run anywhere. However, >> currently, this is not the case with our Gaia apps. The biggest roadblock >> preventing this is our reliance on packaged apps and the security model. >> Once we can finally move away from packaged apps towards *hosted* apps, we >> will be much closer to having *real* web apps that can run anywhere. This >> will also solve our problem with app updates as our Gaia apps could simply >> be hosted on a public web server in the cloud where users receive live >> updates like any other web app. We should have Service Workers available to >> us in FxOS again soon, so our “offline” use case should be covered. So, I >> *think* that means that the only thing really blocking us from >> transitioning to hosted apps is the security model, right? >> >> Firstly let me say I completely agree with you. But “security model” is >> an overloaded term. When you say hosted apps, you are talking about >> websites - there is no difference from a security perspecitve. The security >> model for hosted apps/websites is already well established - that is, >> content is untrusted and APIs must be designed with this in mind. >> >> Compare that to privileged & certified apps: this model involves the >> content being either signed or shipped with the device. i.e. the security >> model is that the content is trusted, and can thus request additional >> permissions. My point is that its a completely different security model. My >> team is working currently to make this model ‘more webby’ but I that will >> not get us closer to a “truly hosted” experience (but I think its still >> very important, but solving a different problem). >> >> If you want a truly hosted Music NGA app, then we need to: >> 1) reduce the permissions that the NGA (and certified only things like >> IAC etc) >> 2) make the essential APIs (e.g. device storage) safe enough to expose to >> the web which involves >> - creating a UX to allow users to safely grant access to music >> files (or even allows pre-granting of the pre-installed music app) >> - refactoring the deviceStorage API to make it safe >> >> 2 is challenging but I think its possible. There is a session this week >> 5pm wednesday to talk about security & UX where I want to talk about some >> ideas here for how we involve the user safely but I think we also need a >> discussion around platform (who’s going to refactor the device storage API >> to make it safe for web…?) >> >> BTW I know the TEF people had a go at refactoring the Music app to be >> completely web. Im on a plane but I think there’s a thread on the old b2g >> list about this which has more details. >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
