On Thursday 10 March 2011 07:14:32 dsimcha wrote: > On 3/10/2011 9:45 AM, Lars T. Kyllingstad wrote: > > Although I agree this would be nice, I don't think std.stdio.File is the > > right place to put it. I think a general streaming framework should be > > in place first, and File be made to work with it. Then, working with a > > gzipped/bzipped file should be as simple as wrapping the raw File stream > > in a compression/decompression stream. > > > > -Lars > > Ok, this seems to be the general consensus based on the replies I've > gotten. Unfortunately, I have neither the time, the desire, nor the > knowledge to design and implement a full-fledged stream API, whereas I > have enough of all three of these to bolt gzip support onto std.stdio. > I guess I'll solve my specific use case at a higher level by wrapping > the C gzip stuff for my DNA sequence reader class, and let someone who > knowns something about good stream design solve the more general problem.
There _have_ been some threads on designing a new stream API, and there are some preliminary designs, but as far as I know, they have yet to really go anywhere. I'm unaware of the stream API really having a champion per se. Andrei has done some preliminary design work, but I don't know if he intends to actually implement anything, and as far as I know, no one else has volunteered. So, a new std.stream is one of those things that we all agree on that we want but which hasn't happened yet, because no one has stepped up to do it. And I do agree that the ability to deal with a compressed file should be part of the stream API (probably as some sort of adapter/wrapper which uncompresses the stream as you iterate through it). But the stream API needs to be designed and _implemented_ before we'll have that. - Jonathan M Davis
