2014-02-24 0:04 GMT+01:00 Markus Scherer <[email protected]>: > Right. If the client code need not collate newly typed strings, then one > good technique is to have the server send the corresponding sort keys. By > the way, ICU makes a strong effort to write very short sort keys. > The size of sort keys does not really matters here. There are in the same order of magnitude as the texts to sort. The problem in dynamic applciations is that there may need to send lots of text to the server to return lots of keys.
The client may want to cache them, but then the application will be bound to the perfomance of the network and the server load, for round tripping response times. In most application web sites, this is simply not an option: users will complain about the slow response time of the applicaton for something that seems abvious for them, such as sortng columns in a long data report mixed with user data input (without having to download it again for the same data presented differently, and without loosing current user input). In some cases, it is also not an option to send this data to the server because it is private to the user and the uer wants that data to be stored elsewhere securely (including on a server that performs nothing else than storage; and cannot offer the collator service). Other applications needing performance of collators are text editors (for client-side search-and-replace while editing; possibly even with support for regexps and collator-based text transforms...).
_______________________________________________ Unicode mailing list [email protected] http://unicode.org/mailman/listinfo/unicode
