> > Anyway, I do generally think it's a bad idea, but I'm not the definitive > word on this by any stretch. Plus if you patch XSP.pm you'll need to patch > XSP::CharsetConv accordingly, so that it converts stuff to the document's > character set. Which of course means that when you use CharsetConv, you'll > be doing two translations - once to the docs charset, then again to UTF-8 > for libxml to be able to understand. I hope you can see how this slows > down everyone's XSP pages ;-)
Yes, I definitely undesrtand the performance issue. I was expecting ti get this :) But otherwise, because we already have to assume that external variables be in UTF-8 compatible encoding ( and you have to convert every expr to your own encoding ) *anyways*, I'm not 100% convinced that this is *such* a bad idea... But I'm willing to trust everybody's judgement on this. Anyway, I just would like to stress that as a multi-byte-character-user the fact that I have to enclose every <xsp:expr>values with <char:charset-convert> to make my database query results show up in xsp is a *royal* pain, and if I weren't so immersed into the world of Perl and XML, I'd probably look for another XML Content Delivery framework -- which is a shame, because in all other aspects I really think AxKit just rocks. So I hope that you guys take a good look at the encoding issues further down the line of development of AxKit ;) Let me know if I can be of any help... thanks, --d --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
