Re: Integrating ICU into Mozilla build

[Henri Sivonen]

On Fri, Dec 7, 2012 at 5:11 AM, Chris Peterson  wrote:
> Can the ICU data be split by locale and bundled with the localized Firefox
> builds?
>
> For example, someone who downloads Firefox's Portuguese build is probably
> interested in ECMAScript internationalization, but only as it pertains to
> Portuguese.

I (strongly) think we should not make the capabilities of the Web
platform dependent on the UI locale of the browser. Precedent exists
for fallback encoding for unlabeled HTML pages, but I think the
precedent should be taken as a “never do this again” learning
opportunity rather than an excuse to introduce more of that.

Given the alternatives of Web apps downloading their own JS-based
collation, sorting and date formatting code and the platform providing
collation, sorting and date formatting functionality inconsistently
depending on the UI locale, I’d much rather have each Web app download
their own code than to provide an inconsistent platform.

Also, the notion that a user with a given browser UI language only
cares about stuff working for that language is incorrect. There are
plenty of people who use Web apps/sites from outside their home locale
box.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Integrating ICU into Mozilla build

[Jonathan Kew]

On 7/12/12 03:35, Robert O'Callahan wrote:

On Fri, Dec 7, 2012 at 4:25 PM, Robert O'Callahan wrote:


On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg <
mozillali...@lindenbergsoftware.com> wrote:


This sounds like non-trivial surgery on ICU. Yes, the APIs are
synchronous. And we don't know whether the time when a user stumbles onto a
Chinese web page that requests Chinese collation is really the best time to
download the data - at that time the user may be roaming in China with a
U.S. data plan...



It may not be easy, but I think it's worth jumping through some hoops to
avoid the download size hit. (Not to mention the B2G and Android footprint
hit.)



One way this could work (straw-man proposal) is that when a locale is
requested that we support but haven't yet downloaded data for, we simply
start the download and pretend not to support that locale until the
download has happened. When the download completes, show an infobar
explaining what happened and suggesting the user reload the page.


This is somewhat analogous to the solution (proposed and prototyped in 
bug 619521 and bug 648548) to provide downloaded-on-demand fonts to 
extend the character coverage when the device lacks any preinstalled 
fonts for a given script/writing system.


Given that ICU data does not have to be built into a monolithic library, 
but can be packaged into multiple data files that are explicitly loaded 
at runtime by the application, I don't think it should be overly 
difficult to engineer such a solution.


JK

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Integrating ICU into Mozilla build

[Benjamin Smedberg]

On 12/6/2012 9:21 PM, Norbert Lindenberg wrote:

The benefit is that the ECMAScript Internationalization API lets developers 
create a more consistent localized experience for their users, with the correct 
date, time, and number formats, the culturally appropriate calendar, correct 
currency symbols, and correct sorting. It also helps avoid latency by removing 
the need to send lists back to the server for sorting.
Is it possible to self-host this functionality in JS? Would it make more 
sense to just build this functionality as a JS library?


This really feels to me like a small feature which isn't worth 20% of 
our footprint, and we should be pushing back to find ways to make it 
possible to implement as a JS library or build in asynchronous 
functionality for dynamic download of locale data as needed, or both.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Try Server wait times - please cancel unwanted/busted runs

[Ed Morley]

On Thursday, 27 September 2012 14:30:01 UTC+1, Ed Morley  wrote:
> > In the meantime please can everyone remember to cancel unwanted/busted Try 
> > runs, to help the overall wait time.
> > 
> > Builds/tests can be cancelled all at once, or on a per job basis:
> > http://people.mozilla.com/~emorley/misc/tbpl-cancel-buttons.png
> 
> A quick reminder:
> 
> Please can people cancel unwanted Try runs -- a glance at Try right now shows 
> many runs that could be cancelled to help with wait times. See the image 
> above for how to mass-cancel via TBPL.
> 

Few months on another quick reminder about this - many more people are now 
cancelling their builds (thank you <3), but looking at Try the last few days 
still shows more people that could be.

This is particularly crucial at the moment, due to the shortage of linux32 test 
slaves (which run both the B2G emulator tests & the linux32 tests). See bug 
818833 for more info.

Thank you :-)

Ed
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Integrating ICU into Mozilla build

[Ehsan Akhgari]

On 2012-12-06 10:11 PM, Chris Peterson wrote:

For example, someone who downloads Firefox's Portuguese build is
probably interested in ECMAScript internationalization, but only as it
pertains to Portuguese.


There is nothing special about a Portuguese build compared to, let's 
say, an English US build, or a build of any other languages.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Try Server wait times - please cancel unwanted/busted runs

[Benoit Girard]

Is there an API we can query to know what the estimated wait time or load
for a slave pool is? Perhaps 'http://trychooser.pub.build.mozilla.org/'
could be modified to give an indication of the load for a particular
platform. I would be more mindful at balancing my load if the information
was provided.

On Fri, Dec 7, 2012 at 9:24 AM, Ed Morley wrote:

> On Thursday, 27 September 2012 14:30:01 UTC+1, Ed Morley  wrote:
> > > In the meantime please can everyone remember to cancel unwanted/busted
> Try runs, to help the overall wait time.
> > >
> > > Builds/tests can be cancelled all at once, or on a per job basis:
> > > http://people.mozilla.com/~emorley/misc/tbpl-cancel-buttons.png
> >
> > A quick reminder:
> >
> > Please can people cancel unwanted Try runs -- a glance at Try right now
> shows many runs that could be cancelled to help with wait times. See the
> image above for how to mass-cancel via TBPL.
> >
>
> Few months on another quick reminder about this - many more people are now
> cancelling their builds (thank you <3), but looking at Try the last few
> days still shows more people that could be.
>
> This is particularly crucial at the moment, due to the shortage of linux32
> test slaves (which run both the B2G emulator tests & the linux32 tests).
> See bug 818833 for more info.
>
> Thank you :-)
>
> Ed
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Try Server wait times - please cancel unwanted/busted runs

[Ehsan Akhgari]

On 2012-12-07 1:54 PM, Benoit Girard wrote:

Is there an API we can query to know what the estimated wait time or load
for a slave pool is? Perhaps 'http://trychooser.pub.build.mozilla.org/'
could be modified to give an indication of the load for a particular
platform. I would be more mindful at balancing my load if the information
was provided.


 is one way of getting 
that information.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Super-review, what shall we do with you?

[Dave Townsend]

On 11/23/12 11:29, Dave Townsend wrote:

On 11/06/12 10:09, Dave Townsend wrote:

We've had a policy requiring super-review for certain kinds of patches
for a long time. It's changed a couple of times but the current policy
(http://www.mozilla.org/hacking/reviewers.html) primarily requires
super-review for any patch that introduces or changes an API. Basically
any function in a JS file or JSM is covered here, or at least that is my
reading of it. The reasoning is pretty straightforward, designing APIs
well up front reduces the maintenance burden in the future and hopefully
means we don't have to make changes that break add-ons.

The problem is that I frequently come across patches that were landed
without super-review despite meeting the requirements. This suggests
that many reviewers aren't aware of the policy or don't have the same
interpretation of it as I do. We probably need to do a better job of
making sure that all reviewers in particular understand the policy and
are following it.

But, I haven't yet seen an issue arise from this lack of SR. Does that
mean that the policy is too restrictive and we need to change it to more
closely match how reviewers are working?

Either we're setting ourselves up for big problems down the road or we
have a policy that is in some cases hindering development. Those are the
extremes of course and the reality is probably somewhere in between, but
I'd like to hear other people's thoughts about this.


I've made a blog post suggesting a change to the definition of what an
API is that requires super-review. I'd appreciate it if people read it
and gave me some feedback:
http://www.oxymoronical.com/blog/2012/11/What-is-an-API


It's a bit difficult to draw a consensus from everyone here but mostly 
it seems that people think the status quo with module owners and 
reviewers making their judgement is working out here. I'm going to email 
all the module owners directly and ask that they look over the policy 
and communicate with their peers about what their expectations are.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Integrating ICU into Mozilla build

[Norbert Lindenberg]

On Dec 7, 2012, at 6:18 , Benjamin Smedberg wrote:

> On 12/6/2012 9:21 PM, Norbert Lindenberg wrote:
>> The benefit is that the ECMAScript Internationalization API lets developers 
>> create a more consistent localized experience for their users, with the 
>> correct date, time, and number formats, the culturally appropriate calendar, 
>> correct currency symbols, and correct sorting. It also helps avoid latency 
>> by removing the need to send lists back to the server for sorting.
> Is it possible to self-host this functionality in JS? Would it make more 
> sense to just build this functionality as a JS library?

I discussed this in the paragraph that you cut off:

>> [...] There are a number of JavaScript libraries for number and date 
>> formatting, but they require applications to load these libraries and the 
>> associated locale data, and their coverage for different calendars, time 
>> zones, and currencies is usually very limited (and where there's more, you 
>> pay with a bigger download size). As far as I know, there's no JavaScript 
>> library that supports localized sorting, so the only solution for 
>> applications is to do all sorting on the server.

For sorting in particular, while the (rather complex) algorithms could be 
ported to JavaScript, it also requires big data tables. Download size is an 
even bigger concern for web applications than for browsers, and even if you 
could assume a shared CDN and caching in the browser, nobody wants to be the 
first one to take the hit.

This is really basic infrastructure that for native applications is provided by 
the OS and for web applications should be provided by the browser.

Norbert

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Try Server wait times - please cancel unwanted/busted runs

[Benoit Girard]

If we could expose the data via a cross domain API in text format I can
modify trychooser to display loaded platforms.


On Fri, Dec 7, 2012 at 2:06 PM, Ehsan Akhgari wrote:

> On 2012-12-07 1:54 PM, Benoit Girard wrote:
>
>> Is there an API we can query to know what the estimated wait time or load
>> for a slave pool is? Perhaps 
>> 'http://trychooser.pub.build.**mozilla.org/
>> '
>> could be modified to give an indication of the load for a particular
>> platform. I would be more mindful at balancing my load if the information
>> was provided.
>>
>
> >
> is one way of getting that information.
>
> Cheers,
> Ehsan
>
>
> __**_
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Next Rendering meeting this Monday, December 10.

[Benoit Jacob]

Hello,

The next Rendering meeting will take place this Monday at 2:30 PM
US/Pacific time. That could be Tuesday in your timezone.

The Rendering meeting is about all things Gfx, Image, Layout, and Media. It
is expected to take place every second Monday.

Please first add your agenda items there:

https://wiki.mozilla.org/Platform/GFX/2012-December-10

* Every second Monday at 2:30 PM Pacific Time
* +1 650 903 0800 x92 Conf# 99366
* +1 416 848 3114 x92 Conf# 99366
* +1 800 707 2533 (pin 369) Conf# 99366 (toll free, Skype)
* Video (Vidyo) link:
https://v.mozilla.com/flex.html?roomdirect.html&key=vu1FKlkBlT29
* Vidyo room 9366 (if you have LDAP and can log in at https://v.mozilla.com)

See you,
Benoit
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Integrating ICU into Mozilla build

[Brian Smith]

Jean-Marc Desperrier wrote:
> ICU is a massive, huge juggernaut. It fits the bill in professional
> application that have no download size constraints, and no
> requirement to support the low end of installed memory size. OS
> support is incredibly more efficient.

Jean-Marc, I don't agree with everything you said but I do agree with this 
part, which I think people might be glossing over too easily. I don't 
understand the fixation on ICU as *the* solution to this problem. If the 
EcmaScript specification is so complicated and so unusual in its design that it 
cannot be easily implemented using widely-deployed system i18n APIs, then IMO 
that spec is broken. But, I highly suspect that it is quite possible to 
implement that spec with OS-provided libraries. Window and Mac have extensive 
internationalization APIs. Why not use them?

I am also unsure about the comments that say imply that even stock ICU is not a 
good choice for implementing this API. Is it *required* to modify ICU to 
implement the JS API, or is it just inconvenient or (slightly?) inefficient to 
use the stock ICU API?

We can ship ICU as a system library on B2G. Some Linux distributions apparently 
ship ICU as a system library so we may be able to make an ICU system library a 
runtime prerequisite for Firefox on Linux, or we could just make Firefox on 
Linux 20% bigger (I don't think Linux users are that particular about the 
download size).

According to previous messages in this thread, Android has ICU as a system 
library, that just isn't exposed as an official NDK library. However, I've read 
that it is possible to dlopen the system libraries and use them; you should 
just be extra-careful about handling the case where the libraries are different 
or missing (e.g. renamed). I think it is worth exploring doing this, and 
falling back to "no JS i18n support" or "we must download a bunch of ICU data" 
when things fail. Also, Android is similar to an open-source project. Perhaps 
we could contribute the glue to provide a usable system ICU to NDK applications 
as a long-term solution. Then the pain and uncertainty for Android would be 
somewhat bounded in time.

Granted, the above ideas are a lot more work than just using ICU everywhere. I 
don't know *how* much more work it would be. But, I think that if an engineer 
came to us and said "Give me one year and I will reduce your download size by 
20% in one year" then I hope we'd consider hiring him to do that. So, IMO, the 
extra work to save download size is justifiable if the feature itself is really 
a high priority.

We may be able to just take the 20% hit on download size on Mac too without 
being too concerned. We didn't/aren't implementing stub installer on Mac, 
right? And, we've been shipping universal binaries on Mac (did we stop that 
yet). Those two things indicate to me we're less concerned about download size 
on Mac. If so, then we may be able to get away with just two implementations: 
One ICU, and one Windows API.

Even if we decided that ICU is the only choice for all platforms, there is a 
middle ground between "Must block the startup of Firefox during installation on 
the download of ICU data" and "Delay downloading the ICU data until a web page 
requests it." We could add an updater for the ICU data that 
downloads/installs/updates the ICU data into the Firefox profile separately 
from Firefox installation and update (so the user doesn't have to wait on the 
ICU data to download to use Firefox during installation or update). Note that 
we already do (did?) something similar, downloading ~45MB of safe browsing data 
on first use. (Actually, I think that we could maybe do something like this for 
WebRTC stuff too, which IIRC is about ~1.5MB of object code.)

Cheers,
Brian
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform