I'm concerned about client localization. I'm sure this has come up, but
I didn't see it in my reading through this thread. How will our
localization community, which I understand has a solid process for
localizing Firefox features in XUL, deal with localizing HTML?
- A
On 8/9/2013 7:31 AM, Lloyd Hilaiel 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
