On Thu, May 20, 2010 at 6:32 AM, Philippe Marschall <span dir="ltr"><<a href="mailto:philippe.marschall@gmail.com">philippe.marschall@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">2010/5/19 Michael Lucas-Smith <<a href="mailto:mlucas-smith@cincom.com">mlucas-smith@cincom.com</a>>:<br>
</div><div><div></div><div class="h5">> The expectation of the GRCodec is that, unfortunately, you will get back a<br>
> String object no matter whether you're doing an encode: or a decode: .. I<br>
> would *LOVELOVELOVE* to return a ByteArray when you call #encode: - but this<br>
> has never worked because Pharo/Squeak could never do it. May be this has<br>
> changed, but none of the code that calls #decode: gives us a ByteArray - all<br>
> of the tests, examples, seaside actual code passes in a String containing<br>
> characters representing bytes. I would really love it if the API had a<br>
> contract like this:<br>
><br>
> GRCodec>>encode: (String)<br>
> ^(ByteArray)<br>
><br>
> GRCodec>>decode: (ByteArray)<br>
> ^(String)<br>
<br>
</div></div>I agree. I believe the first one is doable, I'll hack together a<br>
prototype today. The second is more tricky because the servers<br>
themselves (Comanche and Swazoo) already give us a String which is<br>
actually just a ByteArray.<br><br></blockquote><div>Maybe we could get the servers "fixed" (might imply a mode you can set or something). Obviously the server adaptors can simply deal with it as well, but there's going to be an inefficiency there.<br>
</div></div><br>Julian<br>