<div class="gmail_quote">On Thu, Feb 5, 2009 at 9:22 AM, Philippe Marschall <span dir="ltr"><<a href="mailto:philippe.marschall@gmail.com">philippe.marschall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/2/1 Julian Fitzell <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>>:<br><div class="Ih2E3d">
> Do we really just mean "native" encoding here?<br>
<br>
</div>Yes we mean native, where native means native to your Smalltalk<br>
dialect and not native to your operating system. They may or may not<br>
be the same depending on your Smalltalk dialect and your operating<br>
system ;-)<br>
<div class="Ih2E3d"></div></blockquote><div><br>Yes, understood. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> My point isn't that we need to support conversions to arbitrary<br>
> encodings. My point is that it is easier to understand what is<br>
> happening when you know what the two encodings *are*. We don't have to<br>
> allow (for the moment) anything but UTF-8 for the external encoding<br>
> when UTF-8 is specified as the internal encoding. I have no problem<br>
> with that limitation for now.<br>
><br>
> All I'm saying is if you know your options are "utf-8/native",<br>
> "latin-1/native", or "utf-8/utf-8" then it is perfectly clear what is<br>
> being sent to the browser *and* what you are supposed to be dealing<br>
> with in your image.<br>
<br>
</div>If the options are like this, then I'm cool with it.</blockquote><div><br>Ok, sounds like a sliver of agreement. :) I'm not sure of the top of my head what the best way to provide that view is but I'll file an issue for it.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> I suggest Lukas finish his changes to have the Response encode on the<br>
> fly using the codec specified in the server adaptor. We can revisit<br>
> this [further architectural changes] again for the next release.<br>
<br>
</div>Sure<br></blockquote></div><br>I think Lukas actually ran into problems with this... Lukas?<br><br>Julian<br>