"Boris Popov, DeepCove Labs"<
[hidden email]> wrote:
> Re: GPL, do you mean Base64StreamEncoder in Protocols-Common?
>
> #[1 2 3 4 5] asBase64String
There are actually two solutions in Protocols-Common.
Base64StreamEncoder is the older one that tries to pretend to be a character encoder so that it can be used with the EncodedStream. However base-64 encoding is sort of an inverse of character encoding in that the former turns bytes to characters whereas the latter turns characters to bytes. That's why you end up with this tortured construction (like Paul's example earlier) where you have to turn the bytes into Characters first (technically should be "bytes asStringEncoding: #iso8859_1") so that you can write them into the stream and then you get bytes on the bottom which you really want to be a String, thus the #asString call at the end which should really be "asStringEncoding: #ascii".
That's why we abandoned that one in favor of the B64StreamDecoder, which is used similarly except the associated stream class uses a String at the bottom and accepts bytes at the top. The #asBase64String method shows how it's used, note that the #withEncoding: message is sent to a String rather than ByteArray (unlike the EncodedStream case).
Both implementations are Cincom's falling under the same license as the rest of the product. As far as using base-64 to save space, it should be the same as the default "packed string" encoding of storeOn:, so I wouldn't expect much benefit from switching to base-64 here. Maybe a slightly more appealing / familiar character set, or if you care a more standard encoding, but that's about it.
Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
