Hi Tim.

> If one makes a ReadStream or WriteStream using #on:from:to:, you get to
> stream on the contents of the collection starting at the from'th element
> and ending at the to'th element.
> 
> Unfortunately if you the reset the stream, it will start at the first
> element, no matter what the from index was supposed to be!

This problem is connected with another problem I ran into, and I've
delayed the solution because it was not a priority. When you compress
files, it's very beneficial to compress them together as if they were a
single file. This is called solid compression, and is the modern
equivalent of the a bit more grotesque TAR + COMPRESS Unix trick.

The bad solution would be that the compressor handled all the file
hassle. Well, this would be bad because it would add file lists and
positions and etc which are not connected with compression at all.

Another solution would be to create an object that streamed streams. It
would have a list of streams, start and stop indexes for them, and would
behave like a stream. Because it would have to reimplement a lot of
methods present in Stream, I don't think that it would be a good idea to
subclass someClass in the Stream hierarchy.

Regarding the compression problem, well... it certainly does the trick
of storing names for the compressed archive, in the first file streamed
by the stream scheduler, or... Tar? No... StreamGlue? GluedStreams?
StreamCat would do (perhaps), because of conCATenate... I'm open to name
suggestions here.

I'll be working on it today. Expect a change set later, in the
afternoon.

Andres.