On 12/7/2012 4:39 PM, Norbert Lindenberg wrote:
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:
I think you misunderstood. I was suggesting that the functionality we require be part of the browser and implemented in JS. That would really only affect the "code" weight, not the "data" weight, but since C++ code weight affects the number of initial pages in memory, that could still be significant. And I imagine that a JS library performing those functions might be significantly smaller than the equivalent binary code weight.

And the other messages in this thread discuss ways that we could spread out the download weight of the data tables after the initial installation to reduce the costs, or even make them download-on-demand. Does the API allow for the possibility that a sorting algorithm may not be immediately available?

This is really basic infrastructure that for native applications is provided by 
the OS and for web applications should be provided by the browser.
We still need to weigh the cost of this "basic infrastructure" against its value or the alternatives. Having a client-side sorting algorithm is basically a performance optimization, though a significant one on slow networks.

--BDS

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

Reply via email to