Hi Bulat,
On Tue, 13 Jun 2006 20:08:16 +0400
Bulat Ziganshin
first i considered your library as ready-to-use alternative to Streams and was discouraged. but then i understood that it is only proof-of-concept for alternative class structure and realized that for this purpose it serves very well - everything works just as it should work, every bit of Simon's critique about monolithic Stream class was taken into account
Yes, I deliberately published the library in the early stage, in order to show the design to you and other people interested in the area. If the design will be used by the Streams library, I will consider it a success and be satisfied. Otherwise, I will develop it into a fully-featured library.
moreover, you've implemented this w/o duplicating functionality in read, write and read/write classes and virtually w/o speed penalty, by creating "manager" (you call it Controller) class to switch between reading and writing Port behavior
Now I have got rid of the Controlled class. This change introduces a overhead when more than one read/write buffering transformers are used together, but I think it is a rare case.
about your example of using UTF8+Latin1 encoding on one stream: it shouldn't work for using any encoding AFTER UTF8 (i don't have Unix, so i not compiled your lib and don't make actual tests). imagine that first 10 bytes in file represent 8 UTF8 chars. after decoding, these chars will be represented by 32 bytes (8 UTF-32 values). when you make sCleanup, library just can't know what those 32 bytes read from intermediate buffer correspond to 10 bytes in lower-level stream
Thank you for pointing out the design flaw. I'm going to fix it.
i also specially mentioned your implementation of locking transformer. if i correctly understood, it allows to add locking even when stream is used by two transformer paths (such as UTF8+Latin1), in contrast to my library
Yes, that is my intention. Regards, Takano Akio