Hi, We have finished testing of (1) a "trivial" utf-8 patch and (2) a perl 5.14 related patch
Two of them together are tested with perl 5.8, 5.10, 5.12, and 5.14. That is 5.14 related patch is backward compatible. ( Please consider: versions 5.8 and 5.10 are already in the "End of life" status, and we are expecting a new stable 5.16 this year. http://www.cpan.org/src/README.html ) The utf-8 patch was invented after major reading about perl deltas: http://perldoc.perl.org/index-history.html It works with FF, and Chrome at the client side, and does not depend on language settings in these browsers. (Remember that IE8 does not work with or without these patches.) Hope that Julia will commit both patches later today. 1. "Trivial" utf-8 hack for perls 5.8, 5.10, and 5.12. Main (but not the only) idea here is to explicitly call an operator Encode::_utf8_on() before each call of the Serialization module. This operator has a very useful property. If applied twice it has the same effect as if applied once: A * A = A. It seems, it is this property which makes the hack portable trough all versions of perl. 2. Perl 5.14 needs a special attention. The same "trivial" utf-8 hack is valid here too. But here we need another patch (unrelated to utf-8) specific to perl 5.14 new syntax requirements. The problem is that oxi itself (with OR without utf-8 hack) does not work with perl 5.14. 2a. The reason is that 5.14 is MORE strict about perl syntax compared to any older versions of perl. Say expression foreach my $lang qw( en ru de ) { ... } is an ERROR in perl 5.14 and should be replaced by more parenthesized expression foreach my $lang (qw( en ru de )) { ... } which works in all versions of perl (this latter style is backward compatible). It happens that the code of oxi has multiple instances of both types of programming style. At the moment we see that (with both utf-8 patch and 5.14 patch applied) a CSR with foreign letters is presented correctly. But we can not guarantee that we have fixed all violations of new syntax requirements in the code of oxi by means of this 5.14 patch. And each committer should swear to comply with new syntax requirements from now on? 2b. Another reason is that some functionality of perl 5.14 has moved into external modules. One example which has hit us is a new external dependency for oxi when perl 5.14 is used: Switch.pm This is fixed easily. If we install this module from CPAN, then oxi works with all versions of perl. Now again we can not guarantee that all new external dependencies were noticed. Let us consider these patches as just a "demonstration of the method" patches. They fix a problem reported by Oliver, and some other utf-8 related problems which we were aware of. Most probably both patches miss many other places, that should be patched too. Here we need a collective efforts and feedback. But fixing the code is the easiest part of the story. It triggers a much more complex problem. Maybe we should solve this problem first, and only then go towards ultimate utf-8 and 5.14 related fix. It seems that this "trivial" utf-8 hack and 5.14 related patch should be augmented by - a new social agreement about future programming style, or by - inventing another "clever" hack (instead of a "trivial" one) which would make it very hard to ruin utf-8 support by future careless commits. (You remember how in the past we several times tried to fix big commits which again and again ruined crypto abstraction in oxi, and then finally had to surrender, because other committers had no concern about this crypto abstraction. This time we are not willing even to begin to act as "code protectors".) --- Now about the alternative for the "trivial" patch, a "clever" utf-8 patch. Maybe somebody with system wide understanding about oxi suite could invent a "clever" solution. That is find out, how this method of fixing utf-8 could be moved into the Serialization module (?). So that it will be called "automatically" when needed, and applied universally to all places where we need a special utf-8 attention. Or it could be hidden in some other place where it will be protected against future careless commits. Otherwise each committer should swear to call Encode::_utf8_on() each time when she thinks about utf-8 and each time he forgets to think about it? All the best, Sergei ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
