I'm assuming we're talking about all of the screens on http://people.mozilla.com/~zfang/FirefoxAccount/PiCL_0710.pdf excluding "manage account" and "sign out".
Using existing web content for that seems like a good idea to me. Getting the chrome/content interaction right (for the fundamentals like "make auth work", but also for more trivial stuff like "make Privacy Policy link behave correctly" and "update syncing state on the reset password success page") will certainly push this beyond "just raise a container" in terms of complexity, but it's likely overall simpler than building a custom UI (and it has the other benefits you mention). Gavin On Fri, Aug 9, 2013 at 7:31 AM, Lloyd Hilaiel <[email protected]> wrote: > Chris Karlof and I were talking yesterday, and I was noting how awesome the > implementation approach of Persona on FirefoxOS has been. The, the relevant > code that ships with the device is limited to a container capable of running > web content, and some setup code which invokes a function within the context > of that web content when necessary. Further, the navigator.id. apis are > intercepted by firefoxos, and cause raising of the "trusted" content window > and relaying parameters into it. > > All of the code inside the persona dialog is still loaded live from our > servers. > > This approach has saved us a number of times, and is the thing that allows us > to fix issues related to persona or roll out changes that land on all > firefoxos devices instantly. The other nice thing that this does is provide > a tiny contract between the firefoxos codebase and persona (both of which are > still very dynamic at the moment). > > So as I look at the UX mocks that we need to implement, I wonder why we > wouldn't use the same approach here? Namely, the "setting up sync" window > could be entirely implemented in HTML, and the only desktop client work would > be to raise a container. > > We could still get native key stretching by mapping a couple functions into > that environment, and the client could use them if available. > > Is there any really good reason not to explore this option? > > Gavin / Dolske, how would you guys react to this approach as a way to draw a > clear line between the client and the cloud and accelerate this thing? > > lloyd > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
