On Aug 11, 2013, at 2:39 AM, Gavin Sharp <[email protected]> wrote:
> 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". yes. precisely. lloyd > 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
