On Dec 5, 2013, at 7:48 AM, Max Leske <maxle...@gmail.com> wrote: > Thanks for the input. > > The problem with ReadStream and WriteStream is that they (at least in 2.0 and > 3.0) never supported switching in the first place. #binary and #ascii simply > answer self. That means the collection the stream operates on predetermines > the output. I’ve noticed a couple of different approaches to solving this > problem in the way that streams are used throughout the image and I want to > make a list of those to see if there’s some kind of pattern that maybe leads > to an acceptable version with little changes as opposed to an optimal version > where we have to change a lot of the implemenation details of streams.
thanks such analysis is indeed important. > > Cheers, > Max > > > On 04.12.2013, at 19:45, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> > wrote: > >> Here would be the Xtream way IMHO: >> 1) At the end, the file should be handled as binary. >> 2) A facade BivalentReadStream (and BivalentWriteStream) would be created, >> able to switch encoding >> 3) The implementation would be to wrap either directly over the binary >> stream, or indirectly over an encoded stream which wraps other the binary >> stream. >> 4) For write, the facade should just ensure that buffers (if any) are >> properly flushed, and then just delegate to specialized wrapped streams. >> 5) For read, it might be a bit more involved if some buffer were used in >> intermediate wrappers, because they should push back the excess bytes read >> and restore the state of lower level binary stream... >> In all case, all should happen thru delegation and the facade should be >> rather dumb. >> >> >> 2013/12/4 Sven Van Caekenberghe <s...@stfx.eu> >> >> On 04 Dec 2013, at 13:14, Max Leske <maxle...@gmail.com> wrote: >> >> > Let me see what I can come up with. >> >> To be somewhat compatible with existing streams, your memory stream should >> have the concept of ‘i am binary or textual’ and be able to switch in-place >> between these two states (#binary, #ascii). Depending on its state it should >> then return bytes or characters (or collections thereof). Have a look at >> ZnLimitedReadStream>>#next and/or ZnBivalentWriteStream>>#nextPut: >> >> To be 100% correct, encoding should be selectable. But maybe a default to >> utf-8 would be enough. You could have a look at >> ZnCharacter[Read|Write]Stream for inspiration. >> >> My 2c. >> >> > On 03.12.2013, at 19:36, Damien Cassou <damien.cas...@gmail.com> wrote: >> > >> >> Thanks Max for the report. Do you have an idea on how we could solve the >> >> problem ? The previous behaviour was not acceptable either because the >> >> streams that came out of a memory filesystem were the only ones with >> >> binary content >> >> >> >> On Dec 3, 2013 5:35 PM, "Max Leske" <maxle...@gmail.com> wrote: >> >> Damien, Marcus >> >> >> >> this change breaks a lot of things in FileSystem-Git. I don’t disagree >> >> with the idea that reading characters should be default (one could argue >> >> about it…) but your change makes it IMPOSSIBLE to read bytes because >> >> unprintable characters are discarded! So if my ByteArray is a NULL >> >> terminated string, for instance, I can not check for the NULL termination >> >> anymore. >> >> >> >> Cheers, >> >> Max >> > >> >> >> >
